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Since Intel introduced 
the iSBC 80/10 1:;'ingle Board Computer 
in early 1976, the family of Intel OEM 
Microcomputer 
Systems has grown rapidly:·.·Original equipment 
manufacturers 
and volume end-users 
alike have responded to the concept originated by Intel of having all the functions of a computer - 
cen- 
tral processing unit, memory, input-output and system expansion capability - 
present on one printed cir- 
cuit board. 
• 


The capabilities 
of a single board computer have been enhanced by the creation.of the industry-standard 
MULTIBUS system bus. System expansion 
boards have been introduced 
for memory, serial I/O and 
parallel I/O expansion, as well as analog I/O, DMA controllers and peripheral controllers. A unique feature 
of the MULTIBUS architecture, however, is its capability to support multiple single board computers. This 
capability 
permits sophisticated 
multiprocessing 
configurations 
using standard off-the-shelf 
8·bit and 
16-bit single board computers. The introduction 
of the iSBX MULTIMODULE expansion boards has revolu- 
tionized the concept of the single board computer. Now iSBC host boards may be custom configured with 
iSBX expansion boards based on the I/O requirements of the application. This capability provides lower 
cost, higher performance single board solutions. 
Powerful software tools like the iRMX 80 and iRMX 88 
Real-Time Executives and the iRMX 86 Operatinn System are key members of the iSBC product family. 
They provide users with the tools for quick implementations 
of simple or complex systems. iCS product 
line provides chassis and signal conditioning/termination 
strips as well as board level products which 
were developed specifically 
for industrial users. 


This application 
manual is divided into three sections: iSBC Hardware, iSBC Software and iCS Products. 


It contains all of the current application notes, reliability reports, magazine articles and professional jour- 
nal reprints on the products of the Intel iSBC product family. We have compiled all of this information into 
a single publication 
for your convenience. Please contact us with your questions, comments, and sugges- 
tions on how we may provide you with useful information 
on our products. 
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INTRODUCTION 


The recent 
entry 
of the single board 
computer 
into 


the 
broad 
field 
of electronic 
applications 
is sub- 


stantiating 
the 
bil1ing 
as 
a "super 
component". 


Single 
board 
computers 
provide 
a 
solution 
to 


several 
problems 
that 
have not been solved by the 
use 
of 
conventional 
computers: 
cost, 
size, 
and 


design specialization. 


Many 
potential 
microcomputer 
applications 
have 
been 
overlooked 
because 
of 
the 
design 
tasks 


required 
to build 
a microcomputer 
system. 
These 


tasks traditionally 
include 
interfacing 
of the system 


clock, 
read/write 
memory, 
I/O 
ports 
and 
drivers, 


serial 
communications 
interface, 
bus control 
logic 
and drivers. 
Intel's 
iSBC 80/1 OA enables 
the design 


engineer 
to 
concentrate 
on 
the 
application 
of 
microcomputers, 
rather 
than 
on implementation 
details. 


This 
application 
note 
begins 
with 
an overview 
of 
the Intel® 
iSBC 80! lOA. Readers 
who are familiar 


with 
the iSBC 
80/1 OA may choose 
to skip to the 


applications 
section, 
which 
describes 
the following 
typical 
iSBC 80/1 OA applications: 


• 
The 
iSBC 
80/1 OA used 
for instrumentation 


control 
of a Fluke 
8375 
Digital 
Multimeter. 


• 
The iSBC 80/1 OA used as a SCADA Terminal 
in a communication 
application. 


• 
The iSBC 80/1 OA used for temperature 
moni- 
toring in a process 
control 
application. 


• 
The iSBC 80/1 OA used as an interrupt 
driven 


device controller 
for a Centronics 
printer. 


Each 
example 
shows 
the 
user 
program 
and 
hard- 
ware 
required 
for 
the 
application. 
The 
program 
listings 
are 
interspersed 
with 
the 
text 
describing 


the 
application. 
Both 
8080 
Macro 
Assembly 


Language 
and 
Intel's 
PL/M-80 
are 
used 
in 
the 
examples. 


The 
software 
was developed 
on an Intel® 
Micro- 


computer 
Development 
System 
(MDS). 
The MDS 
provided 
the 
tools 
necessary 
to edit, 
assemble 
or 
compile, 
link 
and 
locate 
the application 
software. 


Hardware 
development 
was facilitated 
by the use 


of Intel's 
In-Circuit 
Emulator 
(ICE 80). For further 
information 
regarding 
the Microcomputer 
Develop- 
ment 
System, 
the reader 
is referred 
to the publica- 
tions 
listed 
at 
the 
beginning 
of 
this 
application 
note. 


OVERVIEW 


The iSBC 80/1 OA is a member 
of Intel's 
complete 


line 
of 
OEM 
computer 
systems 
which 
take 
full 
advantage 
of 
Intel's 
LSI 
technology 
to 
provide 
economical, 
self-contained 
computer 
based 
solu- 
tions 
for OEM applications. 
The iSBC 80/1 OA is a 
complete 
computer 
system 
on a single 6.75-by-12 


inch 
printed 
circuit 
card. 
A block 
diagram 
of the 


iSBC 80/1 OA is shown in Figure 
1. 


Intel's 
powerful 
8-bit n-channel 
MOS 8080A 
CPU 


fabricated 
on a single LSI chip, is the central 
pro~ 
cessor 
for the 
iSBC 80/1 OA. The 8080A 
contains 
six 8-bit general 
purpose 
registers 
and an accumu- 
lator. 
The 
six general 
purpose 
registers 
may 
be 
addressed 
individually 
or in pairs, 
providing 
both 


single and double 
precision 
operators. 


USER 
DESIGNATED 
PERIPHERALS 
D 
D48 PROGRAMMABLE 
PARAllEL 
I/O LINES 


SSC·BO/tOA 


ADDRESS 
BUS 
SYSTEM 


DATA 
BUS 
BD 
S 
MEMORY 


CONTROL 
BUS 
I 
~~g 
.. 
. 
EXPANSION 


1. 
I nterrupts 
originating 
from 
the 
Programmable 
Communications 
I nterface 
and 
Programmable 
Peripheral 
I nterface 
are ju~per 
selectable. 


Figure 1. iSBC 80/10A Block Diagram 


The 
8080A 
has 
a 
16-bit 
program 
counter 
which 


allows 
direct 
addressing 
of 
up 
to 
64K 
bytes 
of 


memory. 
An 
external 
stack, 
located 
within 
any 
portion 
of read/write 
memory, 
may 
be used 
as a 


last in/first 
out 
stack 
to store 
the contents 
of the 


program 
counter, 
flags, accumulator 
and all of the 


six general purpose 
registers. 
A l6-bit 
stack pointer 


addresses 
the 
external 
stack. 
This 
provides 
sub- 


routine 
nesting 
that 
is bounded 
only 
by memory 
size. 


The 
iSBC 
80/IOA 
contains 
IK 
bytes 
of 
read/ 
write 
memory 
using Intel's 
low power static 
RAM. 
All on board 
RAM read 
and write 
operations 
are 
performed 
at 
maximum 
processor 
speed. 
Four 


sockets 
for 
up 
to 8K bytes 
of non-volatile 
read- 


only 
memory 
are 
provided 
on 
the 
board. 
Read- 


only 
memory 
may be added in I K byte increments 


(up 
to 
4K total) 
using 
Intel® 
8708 
erasable 
and 


electrically 
reprogrammable 
ROMs 
(EPROMs) 
or Intel 
8308 
masked 
ROMs. 
Optionally, 
if more 
than 4K bytes are required, 
read only memory 
may 


be added 
in 2K byte 
increments 
(up to 8K total) 


using 
Intel® 
2716 
EPROMs 
or 
2316E 
masked 


ROMs. 
All on-board 
ROM or EPROM 
read opera- 


tions 
are performed 
at maximum 
processor 
speed. 


The iSBC 80/!OA 
contains 
48 programmable 
para- 
llel I/O 
lines implemented 
using two Intel® 
8255 


Programmable 
Peripheral 
Interfaces. 
The 
system 


software 
is used 
to con figure the I/O lines in any 
combination 
of 
unidirectional 
input/output, 
and 


bidirectional 
ports 
indicated 
in Table 
I. Therefore, 
the 
I/O 
interface 
may 
be 
customized 
to 
meet 


specific 
peripheral 
requirements. 
To 
support 
the 
large 
number 
of 
possible 
I/O 
configurations, 
sockets 
are provided 
for interchangeable 
I/O line 
drivers 
and 
terminators. 
Hence, 
the 
I/O interface 


provides 
the 
appropriate 
combination 
of optional 


line drivers 
and 
terminators 
to allow the required 
sink 
current, 
polarity, 
and 
drive/termination 
characteristics 
for 
each 
application. 
The 
48 pro- 
grammable 
I/O 
lines 
and 
signal 
ground 
lines 
are 


brought 
out 
to 
two 
50-pin 
edge connectors 
that 


mate with flat, round, 
or woven cable. 


A programmable 
communications 
interface 
using 


Intel's 
8251 
Universal 
Synchronous/Asynchronous 


Receiver/Transmitter 
(USART) 
is contained 
on the 


iSBC 
80/! OA. 
A 
jumper 
selectable 
baud 
rate 
generator 
provides 
the 
8251 
with 
all 
common 


communication 
frequencies. 
The 8251 
can be pro- 
grammed 
by the 
user's 
system 
software 
to select 


the 
desired 
asynchronous 
or 
synchronous 
serial 
data 
transmission 
technique 
(including 
IBM 
Bi- 
sync). 
The 
mode 
of 
operation 
(synchronous 
or 
asynchronous), 
data 
format, 
control 
character 
format, 
parity, 
and 
asynchronous 
transmission 
rate 
are an under 
program 
con tro!. The 8251 
pro- 
vides full duplex, 
double 
buffered 
transmission 
and 
receive 
capability. 
Parity, 
overrun, 
and 
framing 
error 
detection 
circuits 
are all incorporated 
in the 
8251. 
The 
inclusion 
of jumper 
selectable 
TTY or 
EIA 
RS232C 
compatible 
interfaces 
on the board, 


in 
conjunction 
with 
the 
8251, 
provide 
a direct 


interface 
to 
teletypes, 
CRTs, 
asynchronous 
and 
synchronous 
modems, 
and 
other 
RS232C 
com- 
patible 
devices. 
The 
RS232C 
or TTY 
command 


lines, 
serial 
data 
lines, 
and 
signal ground 
lines are 


brought 
out to a 25-pin edge connector 
that mates 
with 
RS232C 
compatible 
flat, 
round, 
or 
woven 
cable. 


Interrupt 
requests 
may originate 
from six sources. 


Two from 
the 8255's, 
two from the 8251 and two 
from user designated 
peripheral 
devices. 


MODE 
OF OPERATION 


UNIDIRECTIONAL 


PORT 
NO. OF LINES 
INPUT 
OUTPUT 
BIDIRECTIONAL 
CONTROL 
LATCHED 
& 
LATCHED 
& 


UNLATCHED 
STROBED 
LATCHED 
STROBED 


1 
8 
X 
X 
X 
X 
X 


2 
8 
X 
X 
X 
X 
3 
8 
X 
X 
Xl 
4 
8 
X 
X 
5 
8 
X 
X 
6 
4 
X 
X 
4 
X 
X 


1. 
Note: 
Port 
3 
must 
be 
used 
as a control 
port 
when 
either 
Port 
1 or 
Port 
2 are 
used 
as a latched 
and 
strobed 
input 
or a latched 
and 
strobed 
output 
or Port 
1 is used 
as a bidirectional 
port. 


The 8255's 
can generate 
interrupts 
when a byte of 
information 
is ready 
to be transferred 
to the CPU 


(Le., input 
buffer 
full) or a byte of information 
has 
been transferred 
to a peripheral 
device (Le., output 
buffer 
is empty). 


The 8251 
can generate 
interrupts 
when a character 
is ready 
to be transferred 
to the CPU (i.e., receive 


channel 
buffer 
is full) or a character 
is ready to be 
transmitted 
(Le., 
transmit 
channel 
data 
buffer 
is 


empty). 


The user designated 
peripheral 
devices can generate 
two 
interrupts: 
one 
via the 
system 
bus 
and 
the 


other via the I/O edge connector. 


The 
two 
interrupts 
from 
the 
8255's 
and 
the two 


interrupts 
from 
the 825'1 a~e all individually 
mask- 


able 
under 
program 
control. 
The 
six 
interrupt 
request 
lines 
share 
a single 
CPU 
interrupt 
level. 


When 
an 
interrupt 
request 
is recognized, 
a RE- 
START 
7 instruction 
is generated. 
The 
processor 
responds 
by 
suspending 
program 
execution 
and 
making 
a subroutine 
call to a user defined 
interrupt 
service 
routine 
originating 
at 
location 
38 (Hexa- 
decimal). 


iSBC 
80/! OA memory 
and 
I/O 
capacity 
may 
be 
increased 
by 
adding 
standard 
Intel 
memory 
and 
I/O 
boards. 
Modular 
expandable 
backplanes 
and 


card 
cages, 
each 
with 
a fou;-board 
capacity, 
are 


available to support 
multi-board 
systems. 


The 
development 
cycle 
of 
iSBC 
80/!OA 
based 
products 
may 
be significantly 
reduced 
using 
the 
Intellec 
Microcomputer 
Development 
System. 
The 
resident 
macro-assembler, 
PL/M-80 
'compiler, 
text 


editor, 
and 
system 
monitor 
greatly 
simplify 
the 
design, 
development, 
and 
debug 
of user designed 
iSBC 
80/! OA system 
software. 
A diskette-based 


system 
allows 
programs 
to be loaded, 
assembled, 


edited, 
and executed 
faster than using conventional 


paper 
tape, 
card, or cassette 
peripherals. 
A unique 


In-Circuit 
Emulator 
(ICE 
80) 
provides 
the 
capa- 
bility 
of 
developing 
and 
debugging 
software 
directly 
on the iSBC 80/! OA. 


iSBC CONFIGURATION 
OPTIONS 


The iSBC 80/10 
provides 
the user with a powerful 


and 
flexible 
I/O 
capability 
for both 
parallel 
and 


serial 
transfers. 
This 
section' 
discusses 
the 
user 
programmable 
and jumper-selectable 
options, 
and 
bus interfacing. 


SERIAL 
I/O OPTIONS 


The serial I/O interface, 
using Intel's 
8251 USART, 


provides 
a serial data communicatiuns 
channel 
that 


can be programmed 
to operate 
with 
most 
of the 


current 
serial 
data 
transmission 
protocols, 
There 


are three general areas of serial I/O options: 


I. 
choice 
of interface 
type, 
RS232C 
or current 
loop, 


2. 
baud 
rate 
and 
program-selectable 
mode 


options, 


3. 
choice of an interrupt 
mechanism, 


The 
user has the 
choice, 
through 
jumper 
connec- 
tions, 
of configuring 
the serial I/O logic to present 


either 
an RS232C 
or a 20 mA current 
loop inter- 
face to an external 
device, 
If an RS232C 
interface 


is used, 
the 
8251 
can assume 
the 
role of a "data 


set" 
or a "data 
processing 
terminal". 
This enab1es 


the 
serial 
interface 
to 
be 
connected 
to different 
devices 
such 
as modems 
and 
computer 
terminals, 


There 
are two factors 
which 
enter 
into 
the choice 


of baud 
rate. 
They 
are the actual 
clock 
frequency 


used 
to 
drive 
the 
transmit/receive 
clocks 
on the 


8251 
and 
the 
baud 
rate 
factor 
selected 
by a pro- 
grammable 
mode 
instruction 
control 
word 
output 


by the processor 
to the 8251. The baud rate factor 
is used to effectively 
divide the 8251 transmit 
and 


receive 
clocks 
by I, 16 or 64. During normal 
oper- 


ation 
a factor 
of 
16 is selected 
for asynchronous 


transmissions 
from 
9.6K 
to 300 baud. 
A factor 
of 


64 must be used to achieve a baud rate of 110. The 
baud 
rate factor 
is only applicable 
to asynchronous 


transmission, 
as all 
synchronous 
transmission 
is 


done with an implied 
factor 
of one. 


Before 
beginning 
serial 
I/O 
operations, 
the 
8251 
must 
be program-initialized 
to support 
the desired 
mode 
of operation. 
The 
CPU initializes 
the 8251 


by 
issuing 
a set of control 
bytes 
to the 
USART 


device. These control 
words specify: 


• 
synchronous 
or asynchronous 
operation 


• 
baud rate factor 
• 
character 
length 
• 
number 
of stop bits 
• 
even/odd 
parity 
• 
parity/no 
parity 


Refer 
to the iSBC 80/10 and iSBC 80/10A Single 


Board Computer 
Hardware Reference 
Manual or 


the 
"8251 
Application 
Note" 
for 
details 
on the 
control 
words 
used 
to direct 
the operation 
of the 


8251. 


The 
serial I/O logic can be configured 
with 
differ- 


ent 
forms 
of 
interrupt 
request 
mechanisms. 
By 


connecting 
a jumper, 
the user c~n allow the 8251 's 


Receiver 
Ready 
output 
to 
generate 
an interrupt 


request. 
The 
Receiver 
Ready 
output 
goes 
high 


whenever 
the Receiver 
Enable 
bit of the command 


word 
has been set and the 8251 contains 
a charac- 


ter that 
is ready 
to be input 
to the CPU. The user 


can 
also 
choose 
to 
have 
the 
8251's 
Transmitter 


Ready 
or Transmitter 
Empty 
output 
activate 
the 
interrupt 
request. 
The 
Transmitter 
Empty 
goes 
high when 
the 8251 
has no characters 
to transmit. 


Transmitter 
Ready 
is high when 
the 8251 
is ready 
to accept 
a character 
from 
the 
CPU. Both Trans- 


mitter 
Empty 
and 
Transmitter 
Ready 
are enabled 


by setting 
the Transmit 
Enable bit of the command 


word. 
Upon 
receiving 
an interrupt, 
the 
program 


can 
determine 
the 
actual 
condition 
which 
is 


responsible 
for the interrupt 
by reading 
the status 


of the 8251 device. 


PARALLEL 
I/O OPTIONS 


The 
parallel 
I/O interface 
consists 
of six 8-bit 
I/O 


ports 
implemented 
with 
two 
Intel 
8255 
Program- 


mable 
Peripheral 
Interface 
devices. 
Eight 
lines 


already 
have a bidirectional 
driver and termination 


network 
permanently 
installed. 
The 
remaining 
40 


lines 
are 
uncommitted. 
Sockets 
are provided 
for 


the installation 
of active driver networks 
or passive 
termination 
networks 
as 
required 
to 
meet 
the 
specific 
needs of the user system. 


The primary 
considerations 
in determining 
how to 


use each of the six I/O ports are: 


I. 
choice of operating 
mode, 


2. 
direction 
of 
data 
flow 
(input, 
output 
or 


bidirectional), 


3. 
selection 
of interrupt 
mechanism, 


4. 
choice 
of 
driver/termination 
networks 
for 
the port's 
data path. 


Operating 
Modes. 
There 
are three 
basic operating 
modes 
that can be selected 
by the system 
software. 
The 
modes 
of operation 
will be described 
here in 


general 
terms, 
leaving 
it 
to 
the 
reader 
to obtain 


details 
from 
the 
iSBC 
80/10 
and 
iSBC 
80/1 OA 


Single 
Board 
Computer 
Hardware 
Reference 
Manual 
or the "8255 
Application 
Note." 


Mode 
0 is a basic input/output 
functional 
con- 


figuration 
which 
provides 
simple 
input 
and out- 


put 
operations. 
No "handshaking" 
is required, 
data is simply written 
to or read from a specified 


port. 
The outputs 
are latched 
and the inputs 
are 
unlatched. 


Mode 
I 
is 
a strobed 
input/output 
functional 


configuration 
which 
provides 
a means 
for trans- 


ferring 
I/O data 
to or from 
a specified 
port 
in 


conjunction 
with strobes 
or handshaking 
signals. 


The outputs 
are latched 
and are accompanied 
by 


an output 
control 
line which 
indicates 
that 
the 


processor 
has loaded 
the output 
port with a data 


byte. 
The 
input 
data is latched 
when 
accompa- 
nied 
by 
its externally 
operated 
control 
signal. 


Mode 
2 
is a strobed 
bidirectional 
bus 
input/ 


output 
functional 
configuration 
which 
provides 


a means 
for 
communicating 
with 
a peripheral 


device or structure 
on a single 8-bit bus for both 


transmitting 
and 
receiving 
data. 
Handshaking 
signals are provided 
to maintain 
proper 
bus flow 


discipline 
in a manner 
similar to mode 
I. 


Data Flow 
Direction. 
In addition 
to the choice 
of 


operating 
mode, 
the 
user 
may 
also 
specify 
the 


direction 
of data 
flow, 
input 
or output 
from 
the 


8255's. 
At 
the 
time 
of 
RESET, 
the 
8255's 
are 


configured 
into 
the input 
mode 
until 
altered 
by a 
control 
word 
directed 
to the control 
word register. 


When 
an output 
mode 
control 
word 
is received, 


all of the data bits are set to the low output 
state. 


Interrupt 
Mechanism. 
When 
the 
8255 
is 
pro- 
grammed 
to operate 
in mode 
I or mode 2, control 


signals 
are. provided 
that 
can be used as interrupt 


request 
inputs 
to the 
CPU. The 
interrupt 
request 
signals, 
generated 
from 
one of the ports 
(port 
C), 
can be inhibited 
or enabled 
by setting 
or resetting 


the 
associated 
interrupt 
enable 
flip-flop, 
using the 


bit 
set/reset 
function 
of 
port 
C. This 
function 
allows the programmer 
to mask the interrupts 
from 


specific 
I/O 
devices 
without 
affecting 
any 
other 


device in the interrupt 
structure. 


Driver/Termination 
Networks. 
Depending 
on 
the 


direction 
of 
data 
flow, 
the 
user 
will 
select 
the 
appropriate 
TTL line drivers and Intel 
terminators 


that 
are compatible 
with 
the I/O driver/terminator 


sockets 
on the 
iSBC 80/! OA. The 
list of suitable 


line 
drivers 
includes 
those 
with 
inverting, 
non- 


inverting, 
and 
open 
collector 
characteristics. 


There 
are 
two 
types 
of terminators: 
a 220-ohm/ 


330-ohm 
divider or a IK ohm pull-up. 


The 
system 
bus 
interface 
logic 
consists 
of three 
general groups of circuitry: 


I. 
gates 
that 
accept 
the 
various 
bus 
control 
signals, 
the 
interrupt 
request 
lines, 
and 
the 


ready 
indications, 
and 
then 
apply 
these 
signals to the CPU logic elements, 


2. 
the system 
bus drivers, 


3. 
the 
failsafe 
circuitry 
which 
generates 
an 


acknowledgment 
during 
interrupt 
sequences 


and 
during 
those 
cycles 
in 
which 
an 
ac- 


knowledgment 
is 
not 
returned 
because 
a 
non-existent 
device 
was 
inadvertently 
ad- 
dressed. 


Bus 
Interface 
Signals. 
The 
following 
paragraphs 


describe 
portions 
of 
the 
system 
bus 
interfacing 
logic 
relevant 
to 
interfacing 
a user 
device 
to the 
iSBC 80/IOA. 
(Note: 
Whenever 
a signal is active- 
low, 
its 
mnemonic 
is 
followed 
by 
a slash; 
for 


example, 
MRDC/ 
means 
that 
the level on that line 


will 
be 
low 
when 
the 
memory 
read 
command 


is true.) 


BCLK/ 
- 
Bus 
clock; 
used 
to synchronize 
bus 


control 
circuits 
on all master 
modules. 
BCLK/ 


has a frequency 
of 9.216 
MHz. BCLK/ 
may 
be 
slowed, 
stopped 
or 
single 
stepped, 
if 
desired. 


INIT/ 
- 
Initialization 
signal; 
resets 
the 
entire 


system 
to a known 
internal 
state. 


BPRN 
- 
Bus priority 
input 
signal; indicates 
to 
the 
iSBC 80/1 OA that 
a higher 
priority 
mas- 


ter 
module 
is requesting 
use 
of 
the 
system 
bus. 
BPRN 
suspends 
the 
processing 
activity 


and drivers 
of the iSBC 80/1 OA until 
the sig- 
nal goes low. 


BUSY / - 
Bus busy 
signal; indicates 
that the bus 
is currently 
in use. BUSY/prevents 
all other 
master 
modules 
from 
gaining 
control 
of the 
bus. 
BUSY/is 
driven 
by the 
HLDA/ 
output 


from 
the 
iSBC 
80/IOA 
in 
response 
to 
a 
BPRN 
input. 
It 
indicates 
that 
the 
bus 
is 


available. 
MRDC/ 
- 
Memory 
read 
command; 
indicates 
that 
the 
address 
of 
a memory 
location 
has 
been 
placed 
on the 
system 
address 
lines and 


specifies 
that 
the 
contents 
of the 
addressed 
location 
are to be read and placed on the sys- 
tem data bus. 


MWTC/ 
- 
Memory 
write 
command; 
indicates 
that 
the 
address 
of a memory 
location 
has 


been 
placed 
on the 
system 
address 
lines and 
that 
a data 
word 
has 
been 
placed 
on 
the 


system 
data 
bus. 
MWTC/ 
specifies 
that 
the 


data word 
is to be written 
into 
the addressed 
memory 
location. 


IORC/ 
- 
I/O read command; 
indicates 
that 
the 


address 
of an input 
port 
has been placed 
on 
the 
system 
address 
bus 
and 
that 
the 
data at 
that input 
port is to be read and placed on the 


system 
data bus. 


IOWC/ - 
I/O write command; 
indicates 
that the 


address 
of an output 
port 
has been placed on 
the system 
address 
bus and that 
the contents 


of 
the 
system 
data 
bus 
are to be output 
to 


the addressed 
port. 


XACK/ 
- 
Transfer 
acknowledge 
signal; 
the 


required 
response 
of 
an 
external 
memory 


location 
or I/O port 
which 
indicates 
that 
the 


specified 
read/write 
operation 
has been 
com- 


pleted 
(that 
is, data 
has been 
placed 
on, 
or 
accepted 
from, 
the 
system 
data 
bus 
lines). 


AACK/ 
- 
An advance 
acknowledge, 
in response 


to 
a memory 
read 
or 
write 
command, 
that 
allows 
the memory 
to complete 
the specified 
operation 
without 
requiring 
the CPU to wait. 


CCLK/ 
- Constant 
clock; provides 
a clock signal 
of constant 
frequency 
(9.216 
MHz) for use by 


optional 
memory 
and 
I/O expansion 
boards. 


The 
same signal is used to drive both 
CCLK/ 


and BCLK/. 


INTRI/ 
- 
Externally 
generated 
interrupt 
re- 


quest. 


ADRO/-ADRF/ 
- 
16 
Address 
lines; 
used 
to 


transmit 
the 
address 
of the memory 
location 
or I/O port to be accessed. 
ADRF / is the most 
significant 
bit. 


DATO/-DAT7/- 
Bidirectional 
data lines; 
used 
to 
transmit/receive 
information 
to/from 
a 


memory 
location 
or I/O port. 
DAT7/ 
is the 


most significant 
bit. 


Bus 
Acknowledges. 
Further 
distinction 
between 
transfer 
acknowledge 
(XACK/) 
and 
advance 


acknowledge 
(AACK/) 
is required. 
All 
external 
memory 
and 
I/O 
transfer 
requests 
must 
return 
XACK/ 
to the iSBC 80/l0A 
(even if AACK/ is also 
returned). 
XACK/ 
indicates 
that 
data 
has 
been 
placed 
on (read command) 
or accepted 
from (write 
command) 
the system 
data bus lines. AACK/ is an 
advance 
acknowledge 
in response 
to a memory 
or 
I/O 
port 
command. 
It has been 
provided 
because 


the 8080A 
samples 
the ready line before 
valid data 


is required 
on the bus. If this condition 
is properly 


anticipated, 
AACK/ 
can 
be returned 
before 
the 


data is actually 
read, thus allowing 
an earlier opera- 
tion 
to be completed. 
AACK/ 
should 
be used only 


with 
a thorough 
understanding 
of the 
additional 
information 
provided 
in 
the 
iSBC 
80/10 
and 


iSBC 
80/1 OA Single 
Board 
Computer 
Hardware 


Reference 
Manual. 
DMA 
Transfers. 
An 
external 
device 
can make 
DMA transfers 
to or from 
RAM 


expansion 
boards. 
The 
transfer 
is 
coordinated 
with 
the 
iSBC 
80/1 OA 
by 
means 
of 
two 
bus 


signals: 
bus 
priority 
input 
(BPRN) 
and 
bus busy 


(BUSY I). The first step in making 
a DMA transfer 


is 
to 
obtain 
control 
of 
the 
system 
bus. 
This 
is 


achieved 
by asserting 
BRPN 
to the 
iSBC 80/ IOA 


and 
then 
waiting 
until 
the 
iSBC 80/! OA returns 
BUSY /, indicating 
that 
it has relinquished 
control 


of the system 
bus. When this step is completed 
the 
external 
device 
may 
proceed 
with 
its DMA trans- 


fers until 
it is finished. 
At that 
time BPRN should 


be removed 
to 
allow 
the 
iSBC 80/ IOA to regain 


control 
of 
the 
system 
bus. 
It should 
be 
noted 


that 
the 
iSBC 
80/ IOA is placed 
in a hold 
state 
when 
it 
does 
not 
have 
control 
of 
the 
system 


bus. 


APPLICATIONS 


The iSBC 80/! OA may be applied 
to a wide variety 
of applications. 
Specific 
applications 
in four areas 
are 
presented 
in this 
application 
note. 
They 
are 
presented 
to illustrate 
a broad 
spectrum 
of single 
board 
computer 
capabilities 
and 
to 
demonstrate 


the use of various system 
features. 


Microprocessors 
have been used in instrumentation 


for many 
tasks ranging 
from handling 
simple inter- 


face 
functions 
to control 
of the 
analog 
to digital 


conversion 
process. 
The use of a single board com- 


puter 
can 
further 
serve 
in 
the 
application 
of 
instruments 
themselves 
to 
laboratory 
or 
process 
control 
environments. 
It is quite often 
necessary 
in 
these 
applications 
to 
control 
instrumentation 


remotely. 
A number 
of rather 
expensive 
minicom- 


puter-controlled 
solutions 
now exist on the market 


as automatic 
test 
equipment 
(ATE) 
systems. 
The 
iSBC 80/! OA presents 
itself as a cost effective 
solu- 


tion in situations 
where the larger ATE systems 
are 
beyond 
economic 
justification. 


The 
iSBC 
80/! OA can 
be 
the sole CPU element 


in 
the 
system, 
providing 
instrumentation 
control 


and 
computational 
capability; 
or 
it 
can 
supple- 


ment 
a larger 
host 
CPU 
by 
handling 
distributed 


processing 
req uiremen ts. 


Instrumentation 
Control 
Application 
Example 


Most 
instruments 
such 
as DVMs, 
counters, 
data 
loggers, 
synthesizers, 
etc., 
have optional 
data out- 


put 
units 
(DO Us) 
and/or 
remote 
control 
units 
(RCUs). 
It is particularly 
time consuming 
to inter- 


face 
each 
instrument's 
DOU/RCU 
with 
custom- 
digital 
logic. 
Until 
the 
recent 
IEEE-488 
interface 
standard, 
there 
was 
little 
in common 
from 
one 
interface 
to the next. 
The parallel 
I/O lines of the 
iSBC 80/! OA provide 
a common 
interface 
element 


that 
can be adapted 
to a majority 
of the DOUs and 


RCUs available 
today 
by means of software. 


This 
instrumentation 
control 
application 
shows 
how the iSBC 80/!OA 
has been used to control 
and 
read the data 
from 
the data 
output 
unit (DOU) of 
a Fluke 
8375 Digital Multimeter. 


Interfacing 
the 
iSBC 
80/! OA to the 
Fluke 
8375 


DOU 
has 
been 
accomplished 
through 
the 
use of 


three 
parallel 
I/O ports shown 
in Figure 2. An 8-bit 


port 
has been 
used 
to read input 
data 
from 
the 
Fluke 
8375 
DOU. 
Another 
8-bit 
port 
has 
been 


used 
to control 
the multiplexing 
of data 
from 
the 


DOU 
to the iSBC 80/! OA. And, an 8-bit port 
has 


been 
used 
to 
provide 
the 
required 
control 
and 
monitoring 
of 
the 
following 
DOU 
functions: 


busy flag, sample 
sync 
flag, timeout 
enable, 
exter- 
nal trigger and trigger inhibit. 
The following 
listing 
contains 
a complete 
program 


to 
provide 
the 
necessary 
interface 
control 
func- 
tions 
as well as an exercise 
program. 
The program 


listing 
is interspersed 
with 
text 
that 
is used 
to 
clarify the elements 
of the program. 


o ; 
'; 
INSTRUMENTATION 
CONTROL 
APPLICATION 


2 
; 
3 
; 
FLUKE 
8375 
DIGITAL 
MULTIMETER 
4 
; 


5; 
DATA OUTPUT UNIT (DOU) CONTROLLER 
6 ; 
7 ; 
8 


The 
CSEG 
directs 
the 
ISIS-II 
8080 
Assembler 
to 
generate 
a relocatable 
code 
segment. 
Relocatable 
code can later be placed at any memory 
address by 


Intel's 
LOCATE 
program. 
This lets you write your 


program 
without 
worrying 
about 
the application's 
final memory 
configuration. 


9 
10 
; 
11 
CSEG 
12 
; 
lJ 


Equate 
Table. 
The 
following 
table 
is used to give 


symbolic 
names 
to the 
binary 
I/O port 
addresses. 
The 
names 
used 
later 
in 
the 
program 
increase 


reada bili ty. 


14 
15 
; 
16; 
E:CIUATETABLE 
17; 
18 C"R 
EQlI 
OEBH 
19 DAtIN 
EQU 
OE8H 
20 STB 
EQU 
OE9H 
21 
F'LG 
EQU 
0EAH 
22 
TAG 
EQIJ 
OEAH 


23 ; 
24 


; 
3255 
12 
COHTROL 
14QRO REGISTER 


; 
DECADE 
PAIR 
DATA 
INPUT 
PORT 


; 
STROBE 
OUTPUT 
PORT 


; 
FLAG 
INPUT 
PORT 


; 
TRIGGER 
OUTPUT 
PORT 


The exercise 
program 
uses some of the subroutines 


provided 
in 
the 
iSBC 
80/ IOA System 
Monitor 


PROMs. 
The 
addresses 
of 
the 
subroutines 
are 
included 
in the equate 
table. 


25 
26 
; 


27 GETCH 
EQU 
28 
CO 
EQU 
29 
CROUT 
EQU 


30 
NMQUT 
EQU 


31 ; 
J2 


0220H 
; 
GET 
CONSOLE 
INPUT, 
MASK 
OFF 
PARIT'( 


01 E8H 
; 
CONSOLE 
OUTPUT 
OlF3H 
; 
PRINT 
<CR><LF> 


02C2t1 
; 
DISPLAY 
BYTE 
IN 
ACCUM 


The 
use 
of 
the 
iSBC 
80/ IOA parallel 
I/O 
ports 


requires 
that 
the mode 
of operation 
be defined 
for 


each 
port. 
This 
is typically 
done 
by an initializa- 


tion 
subroutine 
executed 
when 
the iSBC 80/ IOA 


is powered 
up or reset. 


8255 
Control 
Word. When the opcode 
field (bit 7) 


of a control 
word 
directed 
to an 8255 
is equal 
to 


one, 
the 
control 
word 
is interpreted 
as a mode 
definition 
control 
word. 
The 
mode 
definition 


control 
word format 
is shown below: 


1071 
D. 
051 041 031 O2 I0, IDO I 
-~ 
L/ 
GROUP. 
"'- 


PORT C (LOWER - 
PC3-PCOJ 


1'" 
INPUT 
0'" OUTPUT 


PORT 
B 
1'" INPUT 
0= OUTPUT 


MODE SELECTION 
O=MODEO 
1 = MODE 1 


/ 
GROUPA 
'\.. 


PORT C (UPPER 
- 
PC7-PC4, 


1 = INPUT 
0'" OUTPUT 


PORT 
A 


, '" INPUT 
0= OUTPUT 


MODE SELECTION 
00= MODE 0 
01 =MODE 1 
lX 
= MODE 2 


/ 
DPCDDE 
"'- 


1" 
MODE SET 


Observing 
the 
schematic 
for the 
iSBC 80/1 OA - 


Fluke 
8375 DOU (Figure 
3), it can be seen that the 


8255 
#2 
should 
be configured 
through 
the use of 


the mode control 
word as: 


Port 4 (A) 
Mode 0 Input 
Port 5 (B) 
Mode 0 Output 


Port 6 (C) 
Bits PC2-PCO 
Output 


Port 6 (C) 
Bits PC5 -PC4 
Input 


The following 
mode control 
word is used: 


33 
34 
; 
35 
; ft. 
8255 
'2 
INITIALIZATION 
SUBROUTINE 
36 
; 


37 
INIf: 


38 
MVI 
A,100110008 
; 
ill 
MODE CONTROL WORD 


39 
OUT 
CwR 
; 
OOTPUT TO 825512 
CNTL 
WD REG 


40 
; 
41 


This coding 
loads the mode 
control 
word 
into 
the 


8255 
#2 
control 
word 
register. 
Additional 
initial- 
ization 
code 
is 
required 
to 
set 
the 
strobe 
and 


trigger 
output 
ports 
to an inactive 
state. 
The sche- 


matic 
shows 
that 
inverting 
drivers 
have been 
used 


for both 
the strobes 
and the trigger. 
When a com- 
mand 
is issued to place port 
5 (B) into the output 


mode, 
bits 
PB7 -PBO 
are 
set 
to 
the 
low output 
state. 
Because 
the 
low outputs 
are then 
inverted 


and 
used as strobes 
to the Fluke 
8375, 
they 
must 
then 
be 
disabled. 
The 
initialization 
subroutine 
concludes 
by disabling 
the strobes 
and trigger. The 
strobes 
are 
signals 
to 
the 
DOU 
which 
enable 
its 


drivers 
to send data to the iSBC 80/1 OA. The trig- 
ger is a signal 
to the 
DOU 
that 
the 
Fluke 
8375 


should 
take a reading. 


MV! 
A,OI'F'H 


our 
5TB 


OUT 
TRG 
RET 


; 
LD MASK TO: 


; 
DISABLE 
STROBES 


; 
DISABLE 
TRIGGER 


External 
Trigger 
Control. 
Two 
subroutines 
are 


implemented 
to 
enable 
and 
disable 
the 
external 


trigger 
mode 
of the instrument. 
These 
subroutines 


use the bit set/reset 
capability 
of the 8255 to inde- 
pendently 
set 
or 
reset 
three 
control 
lines 
of the 


Fluke 
8375 DOU. 


When 
the 
opcode 
field (bit 
7) of an 8255 
control 


word 
equals 
zero, the control 
word 
is a port 6 (C) 


bit set/reset 
command 
word. 


The 
bit 
set/reset 
control 
word 
format 
is shown 


below: 


/ 
BIT SELECT 
"""" 


°3°2°, 
PORT C BIT 


0 
0 
0 
BIT 0 
0 
0 
1 
BIT 1 
0 
1 
0 
BIT 2 


0 
1 
1 
BIT 3 
, 
0 
0 
BIT 4 
, 
0 
1 
BIT 5 
, , 
0 
BIT 6 
, , , 
BIT 7 


The following 
example 
demonstrates 
how the port 


6 (C) 
bit 
set/reset 
control 
word is constructed 
to 


disable 
the Fluke 
8375 
external 
trigger. Note from 


the schematic 
(Figure 
3) that 
port 
6 (C) bit 0 con- 


trols the inhibit 
external 
trigger line. 


50 
51 ; 
52 
; "u 
ENABLE 
EXTERNAL 
TRIGGER 
SUBHOUTINE 
••• 


53 ; 
511 ETRIG: 


55 
!'IV I 
A I 000000008 
; 
LD 
RESET 
BIT 
0 
CONTROL 
¥lORD 
56 
aUT 
CwR 
: 
OUTPUT TO 825512 
CNTL WD REG 


57 
RET 


58 ; 
59 
; 
••• 
DISABLE 
EXTERNAL TRIGGER SUBROUTINE 
••• 


60 
; 


61 
DTRIG: 


62 
MV! 
A,00000001B 
; 
LD SET BIT 
0 CONTROLIoIQAD 
63 
OUT 
CWR 
; 
OUTPUT 
TO 825512 
CNTL 
WD REG 
64 
RET 


65 
; 


66 


Subroutines 
to enable 
and disable the timeouts 
are 


written 
in 
an 
analogous 
fashion. 
The 
timeout 


enable 
line is controlled 
by port 6 (C) bit 2. 


67 
68 
; 


69 
; ••• 
ENABLE TIMEOUTS SUBROUTINE 
••• 


70 
; 


11 
EPOS: 


72 
MV! 
A,OOOOQ1Q18 
; 
LD 
SET 
BIT 
2 
CONTROL 
WORD 


73 
OUT 
CWR 
; 
OUTPUT 
TO 
8255'2 
CNTL 
WD 
REG 
74 
RET 
75 
; 
16 
; ••• 
DISABLE 
TIM£OUTS 
SUBROUTINE 
••• 


77; 
78 
DPOS: 


MV! 
A,000001008 


OUT 
CWR 


RET 


Obtaining 
Readings. 
The 
Fluke 
8375 
DOU allows 
readings 
to 
be 
taken 
in 
one 
of two 
modes. 
The 


first, 
a triggered 
mode, 
assumes 
that 
the external 


triggering 
has not 
been 
inhibited 
and requires 
the 


positive 
edge of a pulse with 
a minimum 
width 
of 


I microsecond 
on 
the 
trigger 
input. 
Setting 
and 


resetting 
the 
port 
6 (C) 
bit 
I produces 
the 8375 
external 
trigger. 
After 
a reading 
is triggered 
the 


8375 
busy 
flag is tested 
until 
the not busy state is 


reached. 
At 
that 
time 
the 
reading 
that 
was 


triggered 
can 
be 
read 
by 
the 
iSBC 80/ IOA. The 


last statement 
in this 
routine 
jumps 
to TKDAT A 


which 
reads 
the 
data 
from 
the 
DOU 
and 
then 
executes 
the return. 


8' 
85 
; 


86 
; 
••• 
SUBROUTINE 
TO 
TAKE 
EXTERNALLY 
TRIGGERED 
READING 
••• 
87 ; 


88 
TRGR: 


89 
90 
91 
92 
93 NT: 
9' 
95 
96 
97 
98 ; 
99 


A,00000010B 
CWO 


A 
CWO 


; 
LD RESET BIT 
1 CONTROL \liORD 


; OUTPUT TO 825502 
CNTL WD REG 


; 
MODIfY 
CONTROL WORD TO SET BIT 
1 


j 
OUTPUT TO 825512 
CNTL WD REG 


Cl.G 


00 1OOOOOB 
NT 
iKDATA 


j 
INPUT 
THE BUSY FLAG 


; TEST 
PORT C BIT 
5 


; 
LOOP UNTIL 
NOT BUSY 


; 
GO READ DATA FROM OOU AND RETURN 


The 
second 
method 
for reading 
the Fluke 
8375 
is 


to rely on the sample 
rate set from the front 
panel 
controls 
and 
to wait 
until 
a full transition 
of the 


busy 
flag is observed. 
This guarantees 
that 
a previ- 


ous reading 
is not mistakenly 
interpreted 
as a new 


reading. 


100 
101 
; 
102 
; 
••• 
SUBROUTINE TO OBTAIN 
NEXT READING ••• 
103 
; 


104 NXTRD: 
105 
106 
107 
108 
NXTWT: 
109 
110 
111 
112 
113 ; 
'" 


; 
INPUT 
THE BUSY FLAG 


; TEST 
PORT C BIT 
5 


; 
LOOP UNTIL 
BUSY WITH 
NEXT READING 


FLG 
00 1OOOOOB 
NX'NT 
TKDATA 


; 
INPUT 
THE BUSY FLAG 


; TEST 
PORT C BIT 
5 


; 
LOOP UNTIL 
NOT BUSY 


; GO READ DATA FRClol OOU AND RETURN 


Notice 
that 
the loops 
beginning 
at NXTWT 
in the 


above program 
segment and at TWT in the previous 


program 
segment 
are identical. 
This 
suggests 
the 


possibility 
of some obvious 
code optimization 
that 


is omitted 
here for the sake of clarity. 


There 
is one subroutine 
remaining 
to complete 
full 


utilization 
of the Fluke 
8375 
DOU capabilities. 
It 
is the subroutine 
to take data from the 8375 DOU. 


The schematic 
(Figure 
3) shows that port 5 (B) bits 


PB4-PBO 
are used to enable the DOU drivers. 
Data 


from the DOU includes: 


• 
5 decades 
of digits 


• 
encoded 
range and overrange 


• 
function: 
Volts 
DC, 
Volts 
AC, Ohms, 
Kil- 


ohms 


• 
modifiers: 
Filter, 
Ext. Ref., Remote 


• 
overload 
• 
trigger 


The 
function 
of 
this 
subroutine 
is to 
read 
five 


bytes 
pf data 
from 
the 8375 
DOU and place them 


in a RAM buffer 
on the iSBC 80/l0A. 


; 
SA YE CURRENT 
STROBE 
; 
STROBE 
DECADE 
PAIR 
; 
READ 
DATA 
; 
PLACE 
DATA 
INTO 
sac 80/10 
RAM 
; 
INCREMENT 
BUfFER 
POINTER 


; 
RESTORE STROBE 


; 
ROTATE 
TO NEXT 
STROBE 
?OSITION 


; 
LOOP 
UNTIL 
BIT 
a STROBE 
OONE 
; 
DISABLE 
ALL STROBES 


This completes 
the software 
required 
to service the 


Fluke 
8375 
DOU. The following 
code consists 
of a 


routine 
to display 
the 
data 
from 
the interface 
on 


the 
console 
output 
device 
and 
a short 
executive 
program 
to 
allow 
exercising 
of 
the 
driver 
sub- 
routines. 


The display 
subroutine 
takes 
5 bytes 
of data from 


the 
RAM 
buffer 
in which 
the 
reading 
has 
been 


stored 
and 
prints 
them, 
2 ASCII 
characters 
per 


8-bit byte, 
on the console. 


; LO NEXT 8HE 
F'R()1 BUffER 
; 
CALL sac 
80/10 
MONITOR 
SUBROlJrINE 
; 
TO DISPLAY 
ACCUHULATOR 
<X:INTENTS 


; 
INCREMENT 
BUFFER 
POINTER 
; 
DECREMENT 
COUNTER 
; 
LOOP FOR 5 DISPLA Y BYTES 


Operator 
Interface. 
The 
short 
executive 
program 


provides 
a tool 
for the purposes 
of exercising 
the 
8375 
DOU driver subroutines. 
The executive 
begins 
by 
calling 
the 
initialization 
subroutine 
and 
then 


continues 
on to prompt 
the operator 
with a '>' on 
the console. 
At that 
point 
the operator 
may enter 


one 
of the 
following 
characters, 
causing 
the 
pro- 


gram to execute 
the specified 
subroutine: 


SUBR 
DESCRIPTION 


T 
ETRIG 
I 
DTRIG 


E 
EPOS 
D 
DPOS 


N 
NXTRD 


S 
TRGR 


X 
DISPLAY 


Enable 
external 
trigger 
Disables external 
trigger 
Enable 
programmed 
timeouts 


Disable 
programmed 
timeouts 


Next reading 
Trigger and get a reading 
Display reading 
buffer 


After 
the operator 
has entered 
a command 
charac- 
ter, 
the 
program 
obtains 
the 
address 
of the 
sub- 
routine 
to be executed 
and 
proceeds 
to set up a 


return 
address 
on the stack. 
This technique 
allows 


a load 
program 
counter 
instruction 
(PCHL) 
to be 


used 
to enter 
the subroutine 
and a return 
instruc- 
tion 
(RET) 
to resume 
execution 
of the executive. 


152 
153 
j 


154 
; 
••• 
SIMPLE 
EXECIJI'IVE 
EXEM:ISE 
PRCXiRAM 
••• 


155 
; 


156 
START: 
157 
158 
159 
EXEC: 
160 
161 
162 
16J 
16' 
165 
166 
167 


168 
EXEeD: 


169 
170 
171 
172 
173 
17' 
175 
EXEC1: 


176 
177 
178 
179 
180,a, 
la2 
18J 
18' 
185 
186 
; 
187 


115 


116 
j 


111 
; If. 
SUBROUTINE 
TO TAKE DATA F'R(}\ 
8315 
OOU .u 


118 
i 
119 TKDATA: 
120 
121 
122 TKO: 
12J 
'" 
125 
126 
127 
128 
129 
lJO 
lJl 
lJ2 
lJJ; 
lJ' 


CROUT 
C 
')' 
cO 


GETCH 
co 
A,C 
B,NQ1DS 
H,CTAB 


; 
EXEC ENTRY POINT 
- 
PRINT 
<CR><LF> 


; 
C LOADED WITH 
PRC»1PT CHARACTER 


; 
(XlKSOLE OUTPUT 


; GET CHND CHAR, 
HASK Off 
PARITY 


; 
PRINT 
THE CHARACTER ON WE 
CONSOLE 


; 
PUT CHARACTER BACK INTO 
THE ACCUH 
; C CONTAINS 
LOOP AND INDEX 
(XlUNT 


; 
HL POINTS 
TO CHND TABLE 


; COMPARE TABLE ENTRY AND CHARACTER 
; 
BRANCH IF' 
EQUAL - 
CMNO RECOONIZED 


; 
ELSE, 
INCREMENT 
TABLE 
POINTER 
; 
DECREMENT LOOP COUNT 
; 
BRANCH IF 
NOT AT TABLE 
END 


; 
ELSE, 
CMND ILLEGAL 
- 
IGNORE 
IT 


H,CADR 
B 
B 
A,M 
H 
H,M 
L,A 
D,EXEX:: 
o 


; 
LD ADR OF TABLE Of 
CMND SUBRS 


; 
ADD WHAT IS 
LEFT 
OF LOOP COUNT 


; 
- 
EACH ENTRY 
IN 
CADR IS 
2 
BYTES 


; 
GET LSP Of 
ADR Of' TABLE ENTRY 1'0 A 
; 
POINT 
1'0 NXT BYTE 
IN 
TABLE 


; GE:": HSP Of 
ADR Of 
TABLE 
ENTRY TO H 


; 
PUT LSP OF' ADR OF' TABLE 
ENTRY 1'0 L 
; 
SETUP RETURN ADR ON WE 
STACK 


The 
command 
and 
address 
tables 
as well as the 


reading 
buffer 
follow 
to complete 
the application 
software. 


188 
1a9 
; 
190; 
CCX1MANDAND ADDRESS TABLES 
191 
; 


192 
CTAB; 


193 
DB 
'XSNDEIT' 


1911Noms 
EQU 
195 
; 
196 CADR; 
197 
198 
199 
200 
201 
202 
20J 
20' 
205 
; 


206; 
READING 
BUFFER AND STACK SPACE 


207 
; 


208 
RDBUF; 


209 
210 
; 


211 
212 
21J 


lJ5 
136 ; 
137 
; 
••• 
SUBROUTINE 
TO DISPLAY 
READING 
BUITER 
ON CONSOLE ••• 


138 
; 


139 
DISPLAY.: 


1110 
LXI 
141 
HV! 


142 D!SPO: 
"J 
'""5 
"6 
"7 
"8 
"9 
150 
; 


151 


o 
ETRIG 
DTRIG 
EPOS 
DPOS 
NXTRD 
TRGR 
DISPLAY 


SUMMARY /CONCLUSIONS 


This 
instrumentation 
control 
application 
has been 


presented 
to 
demonstrate 
the 
simple 
techniques 


used to apply the iSBC 80/1 OA to the task of inter- 
facing instrumentation. 
A natural 
extension 
of this 


example 
would 
include 
the 
control 
of the 
Fluke 


8375 
RCU, 
as well as the 
control 
of many 
addi- 
tional 
instruments 
to 
build 
a small 
ATE 
system. 


BUSY 
FLAG 


SAMPLE 
SYNC 
FLAG 


TIMEOUTS 
ENABLE 


EXTERNAL 
TRIGGER 


EXTERNAL 
TRIGGER 
INHIBIT 


RANGE: 
{ 


" 


FIRST 1 
DECADE 


SECOND: 1 
DECADE 
c 


" 


"1 


THIRD 


DECADE 
c 


" 


'1 


" 
FOURTH 


DECADE 
c 


rl 


'j 
" 
FIFTH 


DECADE: 


(DATA 
OUTPUT 
UNITI 


VCC,T' 
1----- 
,. 
I 
PORT 
6 IC) 


I 
UPPER 


1281 
(J2291 


PC, 


(231) 
(J2271 
I 
PC, 
A,. 
I 
7437 
I 
(22) 
1J2211 


, 
I 


PC, 


(231 
lJ2231 
PCI 
P~~~~~C) 


(21) 
(J2251 
I 
PC. 


12171 
I 
t----n, 
12131 
I 


~ 


12151 
I 


(2221 
I 


-~ 
12181 
I 


-~ 
I 


(220) 
I 


-~ 
(216) 
I 


~ 


12141 
I 


12261 
I 


~ 


(26) 
I 
8255 
-n 
(241 
GRDUP2 


~ 


(2121 


:::::n 


(210) 


11351 


11361 
+-,...., 
0331 


+- ,...., 
(1311 


L ,...., 
(1321 


-----r>o 
II 
341 
Al1_ 
A21 
7437 


(125) 
(J211) 
.A- 


P", 
-,...., 
11271 
~ 
I 
-,...., 
I 
PORT 
51BI 
11291 
I 
(J23) 
~ 
-,...., 
(1281 
,,- 
: 


P., 


~ 


(130l 


(119) 
(J291 
~ 
I 


I 


....• 
I 


P., 


---r-"' 
(121) 


I 
~ 
(123) 
I 
lJ271 


~- 
----F-. 
11221 
~ 


P., 


~ 


11241 
I 


nl3l 
(J251 
~ 
I 


~ 


1115) 
~- 
P•• 


---R 
(117) 
A, 
I 
VCC 


f 


I 


~ 


(116) 
1K 
I 


~ 


(1181 
IJ2351 
I 
I 
PA, 


(151 
lJ2371 
PORT 
4 (AI 


I 
PRG 


~ 


1191 
(J239) 
PA, 


~ 


(1111 
(J24\) 
I 


I 


PA4 


:::::n 


(1101 
I 
A, 
I 
:::::n 


1112) 


f 


1111 
I 
-r 
1131 
IJ2491 
I 
I 
PA, 
-r 


1161 
(J2471 
PA, 
-r 


112) 
(J2451 
I 
PA, 
. 
I 
:::::n 
n 4) 
(J2-431 
I 
PRo 
L ____ 


COMMUNICA nON 


A diverse 
range 
of single board 
computer 
applica- 


tions 
exists 
in the 
field 
of 
communication. 
The 
increase 
in distributed 
processing 
generates 
require- 
ments 
for 
self-contained 
computers 
to 
control 


elements 
of 
a communication 
system, 
increasing 
both the throughput 
and reliability. 


There are many situations 
that necessitate 
monitor- 
ing and 
controlling 
a system 
from 
a remote 
site. 
Typical 
examples 
are systems 
that 
cover large geo- 


graphic 
areas or systems 
in dangerous 
environments 
for human 
operators. 
If the object 
system, 
which 


provides 
the 
actual 
parallel 
inputs 
and outputs 
to 
the 
plant, 
is far from 
the controlling 
system, 
you 


can lower 
costs 
by reducing 
the number 
of inter- 


connecting 
wires via the 
addition 
of multiplexers 
to both 
systems. 
In the extreme 
(and often 
desira- 
ble) 
case 
of 
reducing 
the 
interconnects 
to 
an 


absolute 
minimum, 
all communication 
between 
the 


systems 
takes 
place 
on a single serial data link. 
If 
large distances 
are involved, 
this link can be stand- 


ard 
telephone 
wires. 
For 
moderate 
distances, 
the 
link can be a single twisted 
pair. In either 
case, the 


equipment 
used 
to interface 
the object 
system 
to 
the 
serial 
link is called 
a supervisory 
control 
and 
data acquisition 
(SCADA) 
terminal. 


The 
decision 
to 
replace 
a multitude 
of intercon- 


nects 
with 
a SCADA 
terminal 
is largely 
economic. 


Cables 
and 
their 
associated 
drivers 
and 
receivers 


can represent 
a significant 
part 
of the total 
cost of 


a 
factory 
automation 
project, 
particularly 
if an 


electrically 
noisy 
environment 
requires 
the use of 


shielded 
cables. 
Any 
potential 
savings 
in cabling 


must, 
of course, 
compensate 
for the additional 
cost 
incurred 
by 
adding 
the 
SCADA 
terminal 
to 
the 


system. 


Communication 
Application 
Example 


A SCADA terminal 
demonstrates 
an industrial 
com- 
munication 
application 
of the 
iSBC 80/!OA. 
The 
Intel® 
825 I USART 
provides 
the serial communi" 


cation 
link 
and the two Intel 
8255 
Programmable 
Parallel 
I/O devices provide 
48 parallel 
lines for the 
object 
system. 
A 
block 
diagram 
of 
a 
SCADA 
terminal 
is shown in Figure 4. 


The 
task 
of the 
software 
in this SCADA 
terminal 


example 
is two-fold. 
First, it must continually 
scan 
its parallel 
inputs, 
transmitting 
the status 
of those 
lines in a bit serial 
mode 
using 
the USART. 
And 


second, 
it receives 
bit serial data 
from the USART 
which 
is to be used to update 
the parallel outputs. 


Thus, 
a major 
portion 
of the 
software 
deals with 


the 
communications 
protocol 
on 
the 
serial 
data 


lines. 


Communications Protocol. 
A communication 
pro- 


tocol 
is an 
agreement 
between 
communications 
users that 
defines 
the record 
formats 
used for data 


transmissions. 
The 
protocol 
selected 
for 
this 


SCADA 
terminal 
application 
provides 
the 
follow- 
ing' features: 


I. 
A 
readable 
character 
set 
to 
simplify 
the 


human 
interface. 


2. 
Error 
detection 
by 
means 
of a checksum. 


3. 
Each 
record 
specifies 
the 
number 
of 
data 


bytes 
in 
the 
record 
and 
the 
initial 
port 


number. 


Despite 
its value 
for human 
interface, 
the 
ASCII 
character 
set 
has 
problems 
representing 
8-bit 
binary 
values, since the high-order 
bit is not 
used. 


Therefore, 
each binary 
value is treated 
as two 4-bit 
hexadecimal 
values. 
Because 
hexadecimal 
numbers 


fall in the range 0-9 
and A -F, 
they 
can be repre- 


sented 
as ASCII 
characters. 
However, 
this 
repre- 


sentation 
requires 
twice 
as many 
bytes 
as a pure 


binary 
format. 


Record Format. The information 
encoded 
into the 


ASCII 
hexadecimal 
format 
is grouped 
to 
form 


records. 
Each record 
has a record 
mark 
to flag the 


beginning 
of the record, 
a number 
of ports specifi- 


fication 
(record 
length), 
destination 
output 
start 
port 
number, 
the data 
field itself, and a checksum. 


The record 
format 
described 
below 
is according 
to 


the fields in the record. 


Record 
mark field: Byte 0 


The ASCII 
code 
for a colon 
(:) is used to signal 
the start of a record. 


Number 
of ports field: Byte 
I 


The number 
of data bytes in the record 
is repre- 
sented 
by a single ASCII hexadecimal 
digit in this 


field. 
This 
corresponds 
to the 
number 
of 8-bit 


ports 
to 
which 
data 
will 
be 
output 
by 
the 


SCADA 
terminal 
in a parallel 
fashion. 
The maxi- 


mum 
number 
of data bytes 
in a record 
is 15 (F 


in hexadecimal). 
A record 
length 
of zero 
is a 


special 
case 
and 
can 
be 
reserved 
for 
control 


information. 


Port address 
field: Byte 2 


The 
single 
ASCII 
hexadecimal 
digit 
in byte 
2 


gives the port 
number 
of the initial output 
port. 
The 
first 
data 
byte 
is output 
to the 
port 
indi- 


cated 
by the 
port 
address; 
successive 
bytes 
are 


output 
in successive 
port 
locations 
on the iSBC 


80/1 OA or on expansion 
I/O boards. 


Data field: Bytes 3 to 3+2*(number 
ofports)-I 


An 
8-bit 
binary 
value 
is 
represented 
by 
two 


bytes 
containing 
the 
ASCII 
characters 
0-9 
or 


A-F, 
which 
represent 
a 
hexadecimal 
value 


between 
0 and 
FF 
(0 and 
255 
decimal). 
The 


high-order 
digit is in the first byte 
of each pair. 


Checksum 
field: 
Bytes 
3+2 *(number 
of ports) 
to 


3+2*(number 
of ports)+ I 


The 
checksum 
field 
contains 
the 
ASCII 
hexa- 


decimal 
representation 
of the two's 
complement 


of the 
8-bit 
sum 
of the 
8-bit 
bytes 
that 
result 


from 
converting 
each pair of ASCII hexadecimal 


digits to one byte of binary, 
from the number 
of 


ports 
field 
(the 
number 
of ports 
and 
port 
ad- 


dress constitute 
a pair) 
to and including 
the last 


byte 
of the data 
field. Therefore, 
the sum of all 


the 
ASCII 
pairs in a record 
after 
converting 
to 


binary, 
from 
the 
number 
of ports 
field 
to and 


including 
the checksum 
field, is zero. 


:303A178FFO 


~~ 


ILCh"k,"mF;'1d 
L-oataField 


Statting Port Address 


Number 
01 Port$ 


Record 
Mark 


Design 
Approach 
Using a State 
Diagram. 
Before 


proceeding 
to examine 
the software 
used to imple- 


ment 
the SCADA terminal, 
consider 
how the prob- 


lem might 
have been 
approached 
with 
TTL 
logic 
rather 
than 
a microcomputer. 
The 
design 
would 


likely have been formulated 
with a state diagram 
to 


specify 
the 
transitions 
of 
a sequential 
state 
ma- 


chine. 
The 
sequential-circuit 
operations 
would 


include 
decoding 
the 
serial 
input 
records 
and 


encoding 
the serial output 
records. 
An examination 


of the serial input 
record 
state 
diagram 
(Figure 
5) 


is useful 
in understanding 
some of the procedures 


encountered 
later. 


Notes: 
HAC 
= Hexadecimal 
ASCII character 


LHAC = 
Last Hexadecimal 
ASCII character 


PO 
Parallel output 


The 
receipt 
of an invalid HAC will cause a return 


to state O. 


The receipt 
of a colon at any time will produce 
a 


transition 
to state 
I. 


STATE 
o 
I 
2 
3 
4 


DESCRIPTION 


record 
mark state 


number 
of ports state 
start port number 
state 


high-order 
half of data byte state 


low-order 
half of data byte state 


State 
0 is entered 
at the time 
of initialization. 
All 
state 
transitions 
occur 
when 
the next 
character 
is 


received. 
States 
I, 2, and 
3 are entered 
with 
the 


input 
of a colon 
(:), the number 
of ports and start 


port 
number, 
respectively. 
States 3 and 4 will cycle 
as required 
until 
all the high and low-order 
pairs of 


data 
have been 
input. 
The transition 
from 
state 
4 


to state 
0 occurs 
when 
the last data byte has been 


received. 
If the 
checksum 
is correct, 
the 
parallel 


output 
latches 
are 
loaded 
with 
the 
data 
field 
of 


the record. 


There 
are many 
references 
to the states 
contained 


in this 
diagram 
during 
the 
discussion 
of the soft- 


ware procedures. 
Thus, 
the state diagram 
is used as 
a "flowchart" 
for 
the 
software. 
As in the 
other 
examples 
in this application 
note, 
a textual 
descrip- 


tion 
accompanies 
each 
segment 
of 
code. 
Intel's 


high-level 
programming 
language, 
PL/M-80, 
has 


been 
used 
to show the capability 
to program 
in a 


natural, 
algorithmic 
language 
which 
eliminates 
the 


need 
to manage 
register 
usage 
or memory 
alloca- 


tion. 


SCADA 
Terminal 
Program. 
The 
program 
begins 


with 
a comment, 
that 
is followed 
by the program 


segment 
label 
"SCADA". 
With resident 
PL/M-80, 
all programs 
are considered 
to be labelled 
blocks, 
or 
modules. 
This 
means 
that 
all PL/M 
programs 


must 
begin with a LABEL and a DO statement 
and 


end with an END statement. 


SCADA: 


00; 


All variables 
used in the program 
must be declared 


before 
they 
can be referred 
to by their identifiers. 
This is done 
by means 
of a DECLARE 
statement. 


In addition 
to the declaration 
of variables, 
macros 


are declared 
using the reserved 
word LITERALLY. 
These 
macros 
are 
expanded 
at 
compile 
time 
by 


textual 
substitution. 


DECL.ARE 
SRL$lN$STATE 
BYTE, 


SRL$IH$PRT 
BITE, 
SRL$IN$CHT 
aUE, 
PRL$IN$STATE 
BYTE, 


PRL$IN$STRT$PRT 
BYTE, 
PRL$lN$NHB$PRTS 
BYTE, 


SRL$IN$PRL$OUT$BfR( 
3) 
BYTE, 


PRL$OUT$PRT$O 
LITERALLY 
'OE5H', 
PRL$OUT$PRT$' 
LITERALLY 
'OEAH I, 


PRL$OUT$PRT$2 
LITERALLY 
'OEBH' 
I 


SRL$OUT$STATE 
B'fTE, 
SRL$Ol1TSPRT 
BYTE I 


SRL$OUTSCNT 
aYTE, 
PRl.$OUT$STATE 
BITE, 


PRI..$OU1lSTRT$PRT 
BYTE, 


PRL$OU11NH8$PRTS 
BYTE, 


SRL$OUT$PRL.$IN$BFR( 
11) 
BYTE, 


PRL$lN$PRT$O 
LITERALLY 
'OE4H', 
PRL$IN$PRT$l 
LITERALLY 'Oe6H', 


PRL$IN$PRT$2 
LITERALL'i 
'OE9H', 


USART$CHD 
LlTERALL'i 
'OEDH 
I , 


USART$IN 
LITERALLY 
IQECH', 


USART$OUT 
LITERALLY 
'OECH', 
USAAT,STATUS 
LITERALLY 
'QEDH'. 
USART$l1ODE$INSTR 
LITERALLY 
'QCfH', 


USART$C>ID$INSTR 
LITERALLY 
'025H'. 


TXRDY LITERAU,.Y 
'OOlH'. 
RXROY LITERALLY 
'OO2H'. 


PPI$OiR$l 
LITERAU..Y 
'OE7H', 
PPI$OIR$2 
LITERALLY 
'OEBH', 
PPI$CWD$l 
LITERALLY 
'080H'. 


PPI$CWD$2 
LITERALLY 
'09BH', 


THUE LITERALLY 
'OfFH', 
FALSE: LITERALLY 
'OOOH', 


FOREVER LITERALL'i 
'wHILE 
TRUE', 


8251 
and 8255 
Initialization. 
The INIT procedure 
sets up the 8251 
and 8255's 
and initializes 
several 


variables. 
Interrupts 
are disabled 
to insure 
that 
no 
interrupts 
are serviced 
during 
the execution 
of the 
INIT procedure. 


INIT: 
PROCEDURE; 


DISABLE; 


The serial input 
and serial output 
state counters 
are 


set to state 
O. Port number 
0 is the parallel 
input 


start 
port 
and 
3 ports 
of data are input 
from 
the 


parallel 
ports for serial transmission. 


SRL$IN$STATE 
= 
0; 
SRL.$OUT$STATE 
= 0; 
PRL$IN$STRT$PRT 
= 
0; 
PRL$IH$HHB$PRTS 
= 3; 


The Intel 
8251 
USART 
must 
be set up by loading 


it with mode and command 
instructions. 


The mode instruction 
format 
is shown 
below: 


YL= 


BAUD RATE FACTOR 


00 
-SYN 
MODE 
01·ASYNX1 
10 - ASYN X16 
11 
"ASYNX64 


CHARACTER 
LENGTH 


OO"SBITS 
01 .• 6 BITS 
10"7 
BITS 
1 1 - 8 BITS 


PARITY 
CONTROL 


X 0 .• NO PARITY 
o 1 ••ODD PARITY 
1 1 •• EVEN PARITY 


FRAMING 
CONTROL 


00 
•• NOT VALID 
01·1 
STOP BIT 
10 .• 1~ STOP BITS 
1 1 ·2 
STOP BITS 


SYN CONTROL 


X 0 
INTERNAL 
SYN 


X 1 EXTERNAL 
SYN 
o X 
DOUBLE SYN CHAR 
1 X 
SINGLE SYN CHAR 


The 
8251 
characteristics 
required 
by this SCADA 


terminal 
application 
include 
9600 
baud 
transmis- 


sion and 8-bit characters. 
The parallel inputs 
of the 


8255's 
are 
periodically 
scanned. 
The 
scanning 


frequency 
is 
determined 
by 
the 
baud 
rate 
and 


number 
of 
ports 
of 
data 
being 
transmitted. 
For 


example, 
the 
transmission 
of 
3 
ports 
of 
data 


requires 
II 
characters. 
At a baud 
rate of 9600 the 


approximate 
scan rate is 100 Hz. 


The following 
8251 mode instruction 
is used: 


After 
the 
mode 
instruction 
is sent to the 8251, 
a 


command 
instruction 
is required 
to complete 
the 
8251 initialization. 


The command 
instruction 
format 
is shown 
below: 


TRANSMIT 
ENABLE 
, .• ENABLE 
0" 
DISABLE 


DATA TERMINAL 
READY 


"HIGH" 
WILL FORCE 
OTR OUTPUT 
TO ZERO 


SEND BREAK 
CHARACTER 


1 •• FORCES TllD "LOW" 
0 .• NORMAL 
OPERATION 


ERROR RESET 
1" RESET ALL ERROR 
FLAGS (PE, DE, FE) 


INTERNAL 
RESET 


"HIGH" 
RETURNS 8251 
TO MODE INSTRUCTION 
FORMAT 


The command 
instruction 
enables 
the transmit 
and 
receive functions 
of the 8251. 


The following 
command 
instruction 
is used: 


Output 
instructions 
send 
the 
initialization 
com- 
mands 
to the 8251. 
Note 
that 
previously 
declared 
macros 
are used to literally 
replace 
the mnemonics 
in the following 
lines of code. 


Initialization 
of the 8255's 
is then 
done 
to set up 


the following 
configurations: 


8255 #1 


Port 
I (A) 
Port 2 (B) 
Port 3 (C) 


Mode 0 
Mode 0 
Mode 0 


Output 
Output 
Output 


8255 #2 


Port 4 (A) 
Port 5 (B) 
Port 6 (C) 


Mode 0 
Mode 0 
Mode 0 


Input 
Input 
Input 


The following 
command 
instruction 
is used for the 


8255 #1: 


The following 
command 
instruction 
is used for the 


8255 #2: 


The 
8255 
initialization 
commands 
are given in a 


similar manner 
to the 8251 commands. 


The 
INIT procedure 
concludes 
by enabling 
inter- 
rupts. 


Conversion Procedures. Two conversion procedures 
are required in the program. The first procedure 
produces a hexadecimal 
ASCII character 
from a 


4-bit binary value. A typed 
procedure 
has been 


used which returns a value of the type byte. It is 
called by using its name in an expression. 


15 
1 
OiAR$CONV: 
PROCEDURE (CHAR) 
BYTE; 


16 
2 
DECLARE CHAR BYTE; 


mAR 
= 
CHAR + 
'0'; 
IF 
CHAR > 
'9' 
'mEN 
CHAR 
= 
CHAR 
+ 7; 
RETURN 
CHAR; 


The 
second 
procedure 
produces 
a 4-bit binary 


value from a hexadecimal ASCII character. Because 
this procedure 
is used only when a hexad'ecimal 


ASCII character is expected, 
an illegal character 


(Le., not a 0-9 
or A-F) 
causes the serial input 


state counter to indicate state O. This procedure is 
also typed. The NMB$CONV procedure emphatic- 
ally illustrates 
the point that PL/M-80 performs 


unsigned arithmetic. 
Note that when the ASCII 


value for 
a zero is subtracted 
from the digit, 
NUM = NUM - '0'; a positive number is always 
produced, even if the value of NUM is less than '0'. 


22 
1 
NHB.$CONV: PROCEDURE (MHB) 
BYTE; 


23 
2 
DECLARE NHB BYTE; 


211 
NMB = 
NHB - 
'0'; 
25 
If' 
NHB> 9 ntEN 
26 
00; 


27 
IF 
(NMB ) 
16) 
AND (NHB < 23) 
THEN 
28 
NHB:HH8-7: 
ELSE 
29 
SRL$IN$STATE 
= 
OJ 
30 
END; 
31 
RETURNItiBj 


32 
2 
FJ/DNHIl$CXJHV; 


Parallel Input 
Procedure. A parallel input proce- 


dure is used to input data bytes from the 8255's. 
The data bytes are then transmitted 
by the bit 


serial output device. This procedure also computes 
the 
checksum for the serial output 
record. The 


checksum, 
TEMP2, is initialized 
to contain the 


parallel input number of ports and the start port, 
shifted to fit within a single byte. Each cycle of the 
iterative DO block adds the next data byte to the 
checksum 
and 
places 
the 
input 
data 
into 
the 


SRL$OUT$PRL$IN$BFR 
array until the loop is 


complete. The checksum is then computed as the 
two's 
complement 
of the accumulated 
sum and 


also stored 
in the 
serial input 
parallel output 


buffer. 


33 
1 
PARAI..LEL$IN: PROCEDURE; 


34 
2 
DECLARE (1'D4P" 
'fD(pZ) 
am;; 


35 
2 
TE>WZ 
= 
PRL$IN$NHB$PRTS 
• 
16 
+ PRL$IN$STRT$PRT 
i 


36 
2 
00 
PRL$IN$STATE 
= 
PR1.$IN$STRT$PRT 
TO 


PRL$IN$STRT$PRT 
+ PR1.$IN$NHB$PRTS 
- 
1; 


11 
3 
00 
CASE PRLUN$STATE; 


/. 
PAL 
IN 
PRT a ./ 


38 
11 
TEMP' 
= 
INPUT(PRL$IN$PRT$O); 


Parallel Output Procedure. When a complete serial 
input record has been received and the checksum is 
correct, 
the transition 
from state 4 to state 0 is 


accompanied 
by the parallel output 
of the data 


from the data field of the serial input record. The 
parallel output 
starting port and the number of 


ports of data is contained in the input record and 
is thus used in directing the parallel output opera- 
tion. 
An 
iterative 
DO 
block 
increments 
the 


PRL$OUT$STATE 
index 
variable 
through 
the 


required ports and a DO CASE block selectively 
executes one of the OUTPUT statements for each 
cycle of the loop. 


47 
1 
PARALLEl.$OUT: PROCEDURE; 


4ti 
2 
DECLARE 
T~P 
BYTE; 


119 
2 
DO PRL$OOUSTATE 
= 
PRL$OUT$STRT.$PRT 
TO 


PriL$OUT$STRT$PRT 
+ PRI..$OUT$NH8$PRTS 
- 
1j 


50 
3 
1'£JiP = 
SRI..$IN$PRL$OUT$aFR(PRI..$OUT$STATE); 


51 
3 
00 
CASE PRL$OUT$STATE; 


/. 
PAL 
OUT 
PRT 
0 
./ 


52 
Ii 
OUfPUT(PRL$Ol1T$PRT$O) 
= 
TEMP; 


/- 
PRL OUT PRT 2 -/ 


54 
4 
OOTPUT(PRL$0UT$PRT$2) 
= 
TEMP; 


55 
ENDi 


56 
END; 


57 
2 
END PARALLEL$OUTi 


Serial Input and Output Procedures. The next two 
procedures 
contain the software implementations 


of 
the state 
diagram described 
previously. 
The 


processing during each state of the first procedure, 
the serial character input procedure, is described 
in "the following text. 
The procedure begins by reading a character from 
tlie 8251 arid then converts the character into a 
4-bit binary 
value using the number conversion 


procedure. ;rhe DO CASE block is the mechanism 
by which a program segment is selected to examine 


the 
input 
character, 
provide 
the required 
outputs, 
and 
to 
specify 
the 
transition 
to 
the 
next 
state. 


58 
SER!AL.$Q!.AR$!N:PROC£QURE; 


59 
2 
DECLARE (OiAR, TEltP) 
BITE; 


60 
OiAR '; 
INPUT(USART$IN) 
AND 07F'H; 


61 
TE>tP ;; NKB.$CONV(CHAR); 


62 
2 
00 CASE SRLSIH$STATEj 


State 
0 is entered 
through 
the initialization 
proc- 


ess, at the completion 
of the processing 
of a serial 


input 
record, 
or when an invalid character 
has been 


received. 
The serial input 
state will remain 
0 until a 
colon 
(:) is received, 
at which 
time a transition 
to 
state 
1 is specified. 


/. 
SRL 
IN 
STATE 
0 
= 
RECORD MARK ft/ 
00; 


IF' 
CHAR 
;; 
':' 
THEN 


SRL$IN$STATE 
'; 
'; 


I 


The 
parallel 
output 
number 
of ports 
is obtained, 
the counter 
initialized, 
and a transition, 
to state 2 is 
specified 
from state 
1. 


,ft 
SRL IN 
STATE 
1 
;; 
NMB PRTS 
fit 
00; 
PRL$OUT$NMB$PRTS 
= 
TEMP; 


SRL$IN$CNT 
= TEMP; 


SRL$IN$STATE 
'; 2; 


END; 


In state 
2 the parallel 
output 
starting 
port number 


is obtained, 
the serial input 
port 
is initialized, 
the 
checksum 
is set 
to 
contain 
the 
parallel 
output 


number 
of ports 
and starting 
port, 
and a transition 
to state 3 is specified. 


1ft 
SRL IN STAn: 
2 
'; 
STRT PRT ./ 
00; 
PRL$OIJT$STRT$PRT 
;; TEMPi 


SRl.$lN$PRT 
'; 
TE>1Pj 
CHECKSUM = PRL$OUT$NHB$PRTS'16 
• 
PRL$OUT$STRT$PRT; 


SRL$IN$STATE 
.: 
3; 


END; 


In state 
3 the 
high-order 
half 
of 
a data 
byte 
is 
obtained 
and 
shifted 
into 
the 
proper 
position 
of 
the NEXT$BYTE 
variable. 
A transition 
is specified 


to state 4. 


;1 
SRL IN 
STATE 
3 
'; 
HI 
ORDER HALf 
DATA BHE '1 


00; 
NEXT$BITE 
;; 
TEMp. 
16 ; 


SRL$IN$STATE 
= 
11; 
END; 


State 
4 is the final state and requires 
more process- 


ing than 
the others. 
First, 
a whole 
byte 
of data is 
assembled 
by adding 
the 
low and high-order 
data 
halves, and then 
testing 
to determine 
if the check- 


sum has been received. 
If so, and the checksum 
is 
correct, 
the parallel 
output 
procedure 
is executed. 
Once 
the 
entire 
serial 
input 
record 
has been 
re- 


ceived, 
a transition 
is specified 
to state 
0 whether 


the 
checksum 
is correct 
or not. 
However, 
if the 


serial 
input 
count 
has 
not 
been 
exhausted, 
the 
assembled 
byte 
is 
placed 
into 
the 
serial 
input 
parallel 
output 
buffer 
and a transition 
back to state 
3 is specified. 


/1 SRL 
IN 
STATE 
11 
= 
1.0 ORDER HALf 
DATA BYTE 
'/ 


00; 
NEXT$BrrE 
': 
NEX1lBrre: 
+ 
TE'JoW; 
0iECKSIJI'l 
= CHECKSUH 
+ NEXT$BrrE; 


IF' 
SRL$IN$CNT 
= a THEN 


00; 
IF 
CHECKSlt1 
;; 0 
mEN 


CAU. 
PARAU..EI...$OUT; 


SRL$IN$STATE 
;; 0; 


END; 
ELSE 
00; 
SR1.$IN$PRL$OOT$BFR(SRL$IN$PRT) 
= KEXT$B'tTE; 


SRJ..$IN$PRT 
= SRL$IN$PRT 
..•. 1; 


SRL.$IN$CNT 
= SRI..iIN$CNT 
- 
1; 


SRl.$IN$STATE 
= 3; 
END; 
END; 


The serial character 
output 
procedure 
is similar 
to 
the serial character 
input 
procedure. 
During state 0 


th~ parallel 
inputs 
of the 8255's 
are stored 
in the 
serial output 
parallel 
input 
buffer 
for transmission. 


127 
128 
129 
130 
131 
'?2 


133 
3 
'3' 
135 
1)6 


137 
2 


CHAR = 0; 


00 
CASE SRL$OUT$STATE; 


/* 
SRL OUT STATt: 
0 
= 
RECORD HARK */ 


00; 


CHAR 
= 
':'; 


CALL 
PARALLEL$IN; 
SRL$OUT$STATE 
= 
1; 
END; 


/* 
SRL our 
STATE 
1 
= 
NHB PRTS */ 


00; 


TEMP = PRL$IN$NMB$PRTS; 
SRL$OUT$CNT 
= TEMP; 
SRL$OUT$STATE 
= 2; 


END; 


/' 
SRL OUT STAre 
2 
= 
STRT 
PRT '/ 


00; 
TEMP = PRL$IN$S;rRT$PRT; 
SRL$OUT$PRT 
= TEMP; 
SRL$OUT$STATE 
= 3; 


END; 


/* 
SRL OUT STATE 
3 
= 
HI 
ORDER HALF 
DATA BfTE 
'/ 


00; 
TEMP = SHR(SRL$OUT$PRLSIN$BFR(SRL$OUT$PRT) 
,4); 
SRL$OUT$STATE 
= 4; 


END; 


/* 
SRL OUT STATE 
4 
= 
LO ORDER HALF 
DATA B'(TE 
'/ 
00; 


TEMP = SRL$OUT$PRL$IN$BFR(SRL$OUT$PRT) 
AND OfH; 
IF 
SRL$OUT$CNT 
::; D THEN 


SRL$OUT$S'fAT£ 
= 0; 
ELSE 
00; 
SRL$OUT$CNT 
= SRL$OUT$CNT 
- 
';, 


SRL$OUT$PRT 
= SRL$OUT$PRT 
..•. 1; 
SRL$OUT$STATE 
= 3; 
END; 


, END; 


END; 
/' 
END OF CASES '/ 


IF 
CHAR <> ':' 
THEN 
CHAR = CHAR$CONV(TEHP); 


OUTPUT(USARTSOUT) 
= CHAR; 


END SERIAL$CHAR$OUT; 


Interrupt 
Service 
Routine. 
The 
software 
in 
this 


SCADA 
terminal 
application 
example 
is interrupt 
driven. 
Interrupts, 
which 
occur 
when 
the 
trans- 


mitter 
of the 
825 I is ready 
for another 
character 
or when 
the 
receiver 
has obtained 
a serial charac- 


ter, 
direct 
the 
execution 
of either 
the serial input 


or 
output 
character 
procedures. 
The 
following 
procedure 
is 
entered 
when 
an interrupt 
occurs. 


138 
1 
USART$lNTERRUPT: PROCEOOREINTERRUPT 7; 


139 
2 
DECLARESTATUS BYTE; 


140 
2 
STATUS = 
INPUT(USART$STATUS) j 


141 
IF 
(STATUS AND TXRDY) = TXRDY lliEN 


142 
CALL SERIAL$CHAR$OUT; 


143 
IF 
(STATUS 
AND RXRD't) 
= 
RXRDY THEN 


11111 
CALL 
SERIAL$CHAR$IN; 


1115 
2 
END USART$INTERRUPT: 


Main 
Program. 
The function 
of the main program 
is rather 
simple. 
It calls the 
initialization 
routine 


and 
then 
loops 
"FOREVER." 
Notice 
that 
the 


other 
software 
is executed 
only when 
an interrupt 


occurs. 
Rather 
than 
loop idly while waiting 
for an 
interrupt, 
the 
"main 
program" 
could 
take 
aqvan- 
tage of excess CPU time by processing 
some other 


task. 


SUMMARY /CONCLUSIONS 


Further 
consideration 
should 
be 
given 
to 
error 
checking 
in the implementation 
of a SCAD A termi- 
nal. 
A checksum 
has 
been 
used 
in this 
example 


which 
provides 
some 
error 
detection 
but 
no 


correction. 


The 
industrial- 
communication 
example 
in 
this 


application 
note 
has 
shown 
a SCADA 
terminal. 


Besides 
providing 
a convenient 
forum 
in which 
to 


explore 
the 
use 
of 
PL/M 
in an interrupt-driven 
environment, 
this 
application 
provides 
a realistic 


and 
almost 
fully-developed 
tool 
for 
the 
replace- 
ment 
of 
a multitude 
of 
parallel 
lines. 
Two 
such 
systems 
can be connected 
through 
the serial lines 


to 
provide 
a 
parallel 
to 
parallel 
transmission 
scheme 
as shown in Figure 
6: 
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PROCESS 
CONTROL 


Many 
single 
board 
computers 
have 
already 
been 


applied 
in the field of process 
control. 
Some of the 


common 
denominators 
observed 
in these 
applica- 


tions 
include 
the 
use of A/D 
and 
D/A peripheral 


boards, 
process 
monitoring 
functions 
such 
as 


servicing 
display 
panels 
for 
operator 
interaction, 


and alarm indicators. 


Temperature 
Monitoring 
Application 
Example 


A temperature 
monitoring 
system 
has been 
devel- 


oped 
for the purposes 
of a process 
control 
applica- 


tion example. 
The single open 
loop system 
utilizes 
an AID 
converter, 
a multiplexed 
display, 
switches 


for operator 
control, 
and two alarms. 
A block dia- 


gram 
of the operator's 
panel 
is shown 
in Figure 
8 


and a schematic 
in Figure 9. 


Operator's 
Panel. 
The 
operator's 
panel 
in 
this 


temperature 
monitoring 
system 
contains 
four 


7-segment 
displays 
to show 
the 
temperature, 
two 
light 
emitting 
diodes 
(LEDs) 
that 
indicate 
alarm- 


low 
and 
alarm-high 
conditions, 
and 
six switches. 


The function 
of the switches 
is as follows: 


Set 
Limit 
- 
controls 
whether 
the 
current 
temperature 
reading is to be displayed 
(off) or 


if upper/lower 
limits are to be set (on). 


Set Hi Lo - 
when 
set limit is "on", 
this switch 


controls 
whether 
the 
low (off) 
or high 
(on) 
limit is to be displayed. 


Digit 
Selects 
- 
these 
two 
switches 
control 
the 
selection 
of the digit of the limit which 
is to 
be 
modified. 
The 
four 
binary 
positions 
00, 


01, 
10 
and 
11 
correspond 
to 
the 
four 
7- 


segment 
digits. 


Leave 
It - 
controls 
whether 
the 
digit 
selected 


is to be incremented 
(off) or maintained 
at its 
current 
value (on). 
When this switch 
is "off" 


the digit selected 
is incremented 
every 512 ms 


until 
the 
operator 
turns 
the 
switch 
"on". 


Enable 
Alarm 
- 
when set limit is "off" 
and the 
current 
temperature 
is displayed, 
this switch 
controls 
whether 
the action 
of the alarm indi- 
cators 
is to be enabled 
(on) or disabled 
(off). 


The 
simple 
means 
used 
to 
set 
upper 
and 
lower 


temperature 
limits is similar 
to setting 
the time on 


a digital wrist watch. 


The 
purpose 
of 
the 
software 
is to 
initialize 
the 


system 
and 
then 
to enter 
an endless 
loop 
which 
accumulates 
16 readings, 
updates 
the 
displayed 


reading 
or handles 
limit setting, 
updates 
the display 


latches, 
waits 
4 ms, and 
obtains 
an AID 
reading. 


Temperature Monitoring Program. This application 
example 
has been 
coded 
in Intel's 
resident 
PL/M~ 
80 language. 


PROCESS 
CONTRa.. 
APPLICATION 


OPEN 
LOOP 


TEl'iPERATURE 
f'K)N! I'Oft 


TEHPERATURE$MOHITOR: 


00; 


The 
declaration 
statement 
includes 
some 
dimen- 


sioned 
variables 
with 
INITIAL 
attributes. 
They 


provide 
data 
strobe 
positions, 
a table 
of bit 
pat- 


terns 
to convert 
BCD data 
to 7-segment 
data, 
and 


a table 
of 
the 
powers 
of 
10 for binary 
to BCD 
conversions. 


2 
1 
DECLARE 
READING 
ADDRESS, 


DIGITS(~) 
BYTE INITIAL 
(80H,40H,20H, 
10H). 
BCDT01SEG(1') 
BYTE INITIAL 
(3FH,06H,5BH,4F'H,66H, 
6DH, 7CH,07H, 
7FH, 
61H ,0) 
, 


TENS(4) 
ADDRESS INITIAL 
(1000, 
10D, 10, 1), 
DIGIT$DATA(lO 
BYTE, 
NXT$DIGIT 
BYTE, 


l.IPOATE$COUNT 
BYTE, 
SET$COUNT 
BYTE, 
LIMIT(2) 
ADDRESS, 
ACCUM$RDNG 
ADDRESS. 


CwR 
LITERALLY 
'DEaH', 


SLCT 
LlTERALL't 
'OEAH' 
I 
SEeS 
LITERALLY 
• OEBH' • 


5\1113 
LITERALLY 
'OE9H 
I, 
SEruP$PORTS 
LITERALLY 
'082H'. 


3ET$LIMIT 
LITERALL'i' 
'OOlH'. 
SET$HI$LO 
LITERALLY 
'OO.?H'. 


LEAVE$IT 
LITERALLY 
'010H', 
DIGIr$SLCT 
LlTERALL't 
'OOCH', 
~A8LE$ALARH 
LITERALLY 
'02OH', 


SET$ALARH$LO 
LITERALLY 
'OOlH', 


SET$ALARH$Hl 
LITERALLY 
'OO3H', 
RESET$ALARM$LO 
LITERALLY 
'OOOH', 


RESET$ALARH,$HI 
LITERALLY 
'OO2H', 


The 
analog 
to 
digital 
conversion 
procedure 
has 
been 
coded 
in assembly 
language 
and 
is not 
in- 


cluded 
in this application 
note. 
It is declared 
as an 


external 
typed 
procedure 
with 
no arguments 
and 


returns 
a value 
of 
the 
type 
address. 
The 
value 
returned 
is the 
current 
temperature. 
The 
ATOD 


procedure 
is linked 
later 
in a step 
to produce 
an 


absolute 
load module 
of the entire 
program. 


Bit set/reset 
functions 
of the 8255 
have been used 


to control 
the alarm-low 
and high output 
bits. Use 
of this 
function 
allows 
individual 
bits 
to be con- 


trolled 
without 
affecting 
others 
of port 
C which 


are 
concurrently 
selecting 
the 
digit 
to 
be multi- 


plexed 
on the display. 


5' 
flESET$ALARI'LS: 
PROCEDURE: 


OUTPUT(CWR) 
= 
RESET$ALARM$LO; 


OUTPUT( CWR) 
= 
RESET$ALARrI$HI; 


d 
2 
END 
RESET$ALARI'1S; 


The 
following 
procedure 
is used 
to initialize 
the 


8255 and several program 
variables. 


9 
1 
IN IT: 
PROCEDURE; 


10 
OUrpUT(C",H) 
= SETUPSPORTS; 
11 
CALL RESET$ALAR1"S; 
12 
NXTSDIGIT 
= 
0; 


13 
UPOATgsCOUNT 
= 
0; 


111 
SErSCOUNT = 
7: 
15 
READIKG 
= 
OJ 
16 
ACCUH$RDf«::= 
0; 


17 
LIMIT(O) 
=ססoo; 


ld 
LIMIT( 1) 
= 9999: 


19 
2 
END INIf; 


A multiplexed 
display 
is controlled 
by the 
soft- 


ware. 
Two 
ports 
of an 8255 
are required 
for this 
function 
shown 
in Figure 
9. The first output 
port 


holds 
the data which drives the four 7-segment 
dis- 


plays 
in parallel. 
The second 
output 
port 
contains 
four 
strobes, 
each 
going 
to 
a separate 
common 


cathode 
of one of the 7-segment 
displays. 


The 
update 
display 
procedure 
begins 
by blanking 
7-segment 
data in the output 
port. This step avoids 
shadows 
that 
would 
be produced 
if the 
data 
for 


the 
next 
digit 
position 
were 
loaded 
prior 
to up- 


dating 
the 
strobe. 
The 
strobe 
is then 
advanced, 


retaining 
the 
alarm 
bits 
that 
occupy 
other 
bits of 


the 
same 
output 
port. 
Note 
that 
an output 
con- 


figured 
8255 
port 
can 
be 
read 
with 
an 
8080A 
INPUT 
instruction 
to 
determine 
the 
currently 
latched 
output 
data. 
The 
BCD 
data 
is obtained 


from 
the next 
digit position 
of the DIGIT$DATA 


array 
and 
used 
as 
a subscript 
into 
a 
table 
of 


BCDT07SEG 
data. 
The 
7-segment 
data 
is also 


output 
to 
the 
8255 
port 
in the 


The 
procedure 
concludes 
by 


NXT$DIGIT 
pointer. 


same 
statement. 
advancing 
the 


21 
OUTPUT(SEGS)= 0; 


22 
OUTPUT(Sl.Cf) 
= 
(OIGITS(NXTSOIGIT) 
OR (INPUT(SLCT) 
AND 03H»; 
23 
OUTPUT(SEGS) 
= 
BCDTQ7SEG(DIGIT$DATA(NXT$DIGIT); 
24 
NXTSDIGIT 
= 
(NXT$DIGIT+1) 
AHD 03H; 


2'; 
2 
END DISPLA't$UPDATE; 


Binary 
to BCD 
Conversion. 
Binary 
data 
from 
the 


A/D converter 
must 
be converted 
to BCD before 
it 
can be used by the DISPLA Y$UPDATE 
procedure 


to 
show 
the 
current 
temperature 
reading. 
The 


BINTOBCD 
procedure 
performs 
this 
conversion 


operation. 


26 
1 
BINTOBCD: 
PROCEDURE; 


21 
2 
DECLARE 
(BCD,Il 
B'iT£; 


20 
2 


29 
30 


31 
32 


00 1 = 0 TO 3; 


BCD 
= 
0; 


00 ~mILE READING 
)= 
TENS( 
I); 


READING 
= 
READING 
- 
TENS( 
I) i 
OCD:8CD+l; 


34 
3 


3S 
3 


DHiIT$DATA{ 
1) 
::; BCD; 


END; 


BCD to Binary 
Conversion. 
The reverse conversion 


process 
is also needed. 
That 
is, BCD data 
must 
be 
converted 
to binary. 
This procedure 
is used to take 


limits, 
which 
are set by manipulating 
BCD digits, 


and convert 
them 
to binary 
data 
for use in testing 


against 
current 
temperature 
readings. 
Based 
vari- 
ables 
have 
been 
used 
in 
this 
procedure 
to allow 


access to the actual 
variables 
used as arguments 
in 


the calling program. 


31 
1 
BCDTOBIN: 
PROCEDURE 
(BCD$ARRAY$ADR 
I BIN$DATA$ADR); 


3d 
2 
DECLARE 


(BCD$ARRAY$ADR, 
BIN$DA 
rA~ADR) 
ADDRESS, 


(BCD$AHRAY 
BASED 
BCD$ARRAY$ADR) 
(4) 
BYTE, 


(BIN$DATA 
BASED 
BIN$DArA$ADR) 
ADDRESS, 


I 
BITE; 


39 
BIN$DATA 
::; 0; 


40 
OOI::;OT03i 


/* 
BIN$DATA 
= 
BIN$DATA*10 
+ 
BCD$ARRAY(I) 
*/ 


41 
BIN$DATA 
::; SHL(BIN$DATA, 
1) 
+ 
SHL(BIN$DATA,3) 
+ 
BCD$ARRAY(I) 
i 
42 
END; 


Updating 
the Display. 
The 
UPDATE 
procedure 
is 


entered 
each 
time 
16 readings 
have 
been 
taken 


from the A/D converter. 
The UPDATE$COUNT 
is 


reset and the operator 
switches 
are input 
to control 


the 
execution 
path 
through 
the 
procedure. 
The 


accumulated 
reading, 
which 
is the total 
of 16 A/D 


readings, 
is divided 
by 
16 to 
obtain 
an average 


reading. 
Then 
the 
accumulated 
reading 
is zeroed. 


44 
1 
UPDATE: PROCEDUREj 


45 
2 
DECLARE (SIrlT$FLG,HI$LO,DIGIT) 
BYTE; 


46 
UPDATE$COUNT= 
15j 


47 
SW1'$FLG= 
INPUT(SWTS) j 


48 
READING = SHR(ACCUM$RDNG,4); 


49 
ACCUM$RDNG= 
0; 


Setting Limits. 
If the 
set limit 
switch 
is ON, the 


limits 
are to be dealt 
with 
instead 
of testing 
and 


displaying 
the 
current 
temperature 
reading. 
The 


alarms 
are reset 
during 
limit setting. 
The specified 


limit 
is converted 
to BCD and 
then 
the 
Leave-It 


switch 
is tested 
to see if the digit selected 
is to be 


incremented 
or held constant. 


IF 
(SflT$fLG 
AND SET$LIMIT) 
= SET$LIMIT 
THEN 


DO; 
CALL RESET$ALARMS; 
HI$LO 
= 
SHR«SWT$FLG AND SET$HI$LO), 
1); 


READING = 
LIMIT(HI$LO); 


CALL BINTOBCDj 
If 
(SWT$fLG AND LEAVE$IT) 
<> LEAVE$IT THEN 


Another 
counter 
is 
used 
to 
control 
digit 
incre- 


menting. 
Its purpose 
is to control 
the rate at which 


the 
selected 
digit is to be incremented. 
The major 


loop 
in 
the 
program 
has 
a 4-millisecond 
delay. 
Thus, 
16 
A/D 
conversions 
require 
a 
period 
of 


64 ms which 
provides 
an update 
frequency 
of 16 


readings 
per second. 
This is too fast to accurately 


select 
a desired 
digit 
which 
is being incremented. 


SET$COUNT 
insures 
eight 
update 
periods 
(512 


ms) 
between 
each 
increment. 
After 
the 
digit 
has 


been 
incremented, 
the 
BCD 
limit 
value 
is con- 


verted 
back 
to binary 
to set the 
respective 
limit. 


This 
concludes 
the 
action 
taken 
when 
setting 


limits. 


57 
00; 


5d 
If 
SET$COUNT = 
0 THEN 
59 
ooj 


60 
SET$COUNT = 7; 


61 
DIGIT 
= SHR({SWT$FLG AND DIGIT$SLCT) ,2); 


62 
IF 
DIGlT$DATA( DIGIT) 
= 
9 THEN 


63 
OIGlT$DATA(DIGIT) 
= 
OJ 


ELSE 


611 
DIGIT$DATA(DIGIT) 
= 
DIGIT$DATA(DIGIT) 
+ 
1; 


65 
CALL BCDTOBIN(.DIGIT$DATA,.LIMIT(HI$LO)) 
j 


66 
END; 
ELSE 


~ 
END; 
SET$COUNT= 
SET$COUNT- 
1j 


69 
END; 


Testing the A veraged Reading. 
If 
the 
set 
limit 


switch 
is OFF, 
then 
the averaged 
reading 
is to be 


tested 
and displayed. 
The averaged 
reading 
is con- 


verted 
to 
BCD 
and 
then 
a test 
is performed 
to 


determine 
whether 
the 
reading 
is to be compared 


with the upper and lower limits. 


ELSE 


70 
OOj 


71 
CALL BINTOBCD; 
72 
IF 
(SIoIT$FLG AND ENABLi$ALARM) = ENABLE$ALARMTHEN 


The 
reading 
is compared 
with 
both 
the upper 
and 


lower 
limits 
if the 
alarms 
have been 
enabled. 
The 


results 
of 
the 
tests 
are used 
to set and 
reset 
the 


corresponding 
alarm output 
bits. 


73 
l' 
15 


16 
, 


DO; 
If 
HEADING < LIMIT(D) 
THEN 
OUTPUT(CWR) = SET$ALARM$LOj 
ELSE 
OUTPUT(CWR) = 
RESET$ALARM$LOj 


Ir' HEADING> 
LIMIT( 
1) THEN 
OUTPUT(CflR) 
= SET$ALARM$HIj 
ELSE 
OUfPUT(CflR) 
= 
RESET$ALARM$HI; 


If the alarms 
are not enabled, 
both 
the alarms 
are 


reset to the "off" 
condition. 


Main Program. The main program 
is shown 
below. 


Its purpose 
is to initialize 
the system 
and then 
to 
cycle, 
continuously 
executing 
the code 
previously 


described. 


85 
1 
00 FOREVERj 


86 
2 
ACCUM$RDKG= 
ACCUM$RDNG+ Rt:-:ADING; 


81 
IF 
UPDATE$COUNT= 
0 THEN 
88 
CALL UPDATEj 
ELSE 
89 
2 
UPDATE$COUNT= 
UPDATE$COUNT- 
1j 


90 
CALL DISPLA'l'$UPDATE; 


91 
CALL TIME(40)j 
92 
READING = ATODj 


93 
2 
END; 


SUMMARY/CONCLUSIONS 


The 
goal of this application 
example 
is to demon- 


strate 
some of the common 
functions 
required 
for 


process 
control 
systems. 
Rather 
than 
show a small 


portion 
of 
a larger, 
more 
complex 
problem, 
this 


example 
was chosen because 
it presents 
a complete 


solution 
to a smaller problem. 
In summary, 
refresh- 


ing a multiplexed 
display 
was shown. 
Conversion 


procedures 
for binary 
to BCD and BCD to binary 


were 
used. 
A simple 
technique, 
in terms 
of hard- 


ware 
requirements, 
was 
used 
to enter 
lower 
and 


upper 
test 
values. 
And, 
limits 
testing 
was 
done, 


providing 
alarm indicators. 
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I/O DEVICE 
CONTROLLER 


Peripheral 
processors 
have 
become 
common 
ele- 


ments 
in computer 
systems 
of all sizes and capa- 


bilities. 
The 
purpose 
of 
such 
a 
processor 
is to 
relieve 
a central 
processor 
from 
the 
burden 
of 
handling 
I/O 
devices. 
In effect, 
it is a form 
of 


distributed 
processing. 
The 
iSBC 
80/! OA can be 


used 
as a peripheral 
processor 
and/or 
as an I/O 


device 
controller. 
In such a capacity 
it can signifi- 


cantly 
reduce 
the amount 
of hardware 
required 
to 


interface 
peripherals. 
Because 
the 
iSBC 
80/! OA 


controls 
only 
I/O, 
it is of little 
consequence 
that 


it must 
do a great 
deal of detail 
work that 
other- 


wise 
wastes 
the 
processing 
capability 
of a larger 


cen tral processor. 


Consider 
the 
activity 
of producing 
a listing 
on a 
line 
printer. 
The 
overhead 
in 
maintaining 
a pro- 


gram 
in the 
queue 
of a central 
processor 
which 
is 
producing 
data 
for 
a 
line 
printer 
can 
seriously 
impact 
system 
throughput. 
If, however, 
the 
pro- 


gram 
were 
to send 
the list to a disk file and then 


command 
a peripheral 
processor 
to take care of the 


printing, 
a 
significant 
improvement 
in 
system 


performance 
may 
be achieved. 
Printers 
represent 


one example 
of a large number 
of I/O devices that 


can 
be 
controlled 
by 
an 
iSBC 
80/ IOA. Other 


devices 
include 
cassettes, 
magnetic 
tape 
drives, 
paper tape readers 
and punches, 
etc. 


Character 
Printer 
Controller 
Application 
Example 


The 
control 
of a Centronics 
306 character 
printer 


is 
used 
as 
an 
I/O 
device 
controller 
application 


example. 
This 
example 
shows 
the 
interrupt 
capa- 


bility 
of mode 
I 8255 
operation. 
A block diagram 


of the printer 
controller 
is shown in Figure 
10 and 


a schematic 
in Figure 
II. 


When the mode 
I or mode 2 configuration 
is used, 


software 
is generally 
required 
to support 
interrupts 


used 
in conjunction 
with 
handshaking 
operations. 


Software 
routines 
written 
for an interrupt 
driven 
environment 
tend 
to be more complex 
than status 


driven 
routines. 
The 
added 
complexity 
is because 


interrupt-driven 
systems 
are constructed 
such that 


other 
software 
tasks are run while the I/O transac- 


tion 
is in progress. 
A software 
routine 
that controls 


a 
peripheral 
device 
is generally 
referred 
to 
as a 


device 
driver. 
One 
method 
of 
implementing 
an 
interrupt-driven 
device 
driver 
is to 
partition 
the 


device 
driver 
into 
a "command 
processor" 
and an 
"interrupt 
service routine." 
The command 
proces- 


sor is the 
module 
that 
validates 
and initiates 
user 


program 
requests 
to the device driver. 
A common 


method 
of passing information 
between 
the various 
software 
programs 
is to have the requesting 
routine 


provide 
a device 
control 
block 
in 
memory. 
The 


device 
control 
block 
used 
in 
this 
application 
example 
is shown in Table 2. 


NAME 
POSITION 
DEFINITION 


Status 
Byte 0 
A 1·byte field which defines the completion 
status of an I/O. 


00 = Good completion 
01 = Error - command 
already 
in progress. 


Buffer Address 
Byte 1,2 
Pointer to the start of the data to print. 


Character 
Count 
Byte 3 
Count of the number 
of characters 
to print. 


Character 
Byte 4 
The number 
of characters 
transferred. 
Transferred 
Count 


Completion 
Byte 5, 6 
Address of a user supplied 
routine 
which will be called after the I/O has been 


Address 
performed. 


The 
command 
processor 
validates 
the 
transaction 


and initiates 
the operation 
described 
by the control 


block. 
Control 
is then 
returned 
to the 
requester 


so that 
other 
processing 
may 
proceed. 
The 
inter- 


rupt 
service routine 
processes 
the remainder 
of the 
transaction. 


Interrupt 
Service 
Routine 
Requirements. 
The 


interrupt 
service 
routine 
requires 
the 
following 


functions: 


I. 
The 
state 
of the 
machine 
(registers, 
status, 
etc.) 
must 
be saved 
so that 
it may 
be re- 


stored 
after the interrupt 
is processed. 


2. 
The 
source 
of the interrupt 
must 
be deter- 


mined. 
The hardware 
may support 
a register 


which 
indicates 
the 
interrupting 
device, 
or 


the 
software 
may 
poll 
the 
device 
status 
registers. 


3. 
Data 
must 
be passed 
to or from 
the device. 


4. 
Control 
must 
be 
passed 
to 
the 
requesting 
routine 
at the completion 
of the I/O. 


5. 
The 
state 
of the 
machine 
must 
be restored 


before 
returning 
to the interrupted 
program. 


Printer Controller Program. The 
software 
for this 
application 
has 
been 
coded 
using 
Intel® 
8080 


Macro Assembly 
Language. 


o ;1······ 
2 
; 


3 
; 
I/O 
DEVICE 
CONTROLLER 
APP.LICATION 
, ; 


5 
; 
INTERRUPT 
DRIVEN 
6 ; 
1 
; 
CHARACTER 
PRINTER 
8 ; 
9 ;••••• 


The 
following 
program 
equates 
are 
used 
to 
allow 
symbolic 
reference 
to 
the 
8255 
ports. 
Group 
# I 


8255 
on 
the 
iSBC 
80/1 OA has been 
used 
because 
it will support 
mode 
I operation. 


10 i 
11······ 
12 
; 
PR(X;RAI'l 
EQUArES 
13 
j ••••• 


lil 
PORTA 
EQU 
OE4H 
15 PORTB 
EQU 
0E5H 
16 PORTe 
EQU 
OE6H 
17 
C\IIR 
EQU 
OE7r1 


j 
8255 
PORT A 


j 
8255 
PORT B 


; 
8255 
PORT C 


; 
8255 
CONTROL WORD REGISTER 


An initialization 
control 
word 
sent to the control 


word 
register 
of the 
8255 
will set up the desired 


configuration. 


18 
; 
19 ;f•••• 
20; 
21 
; 
22 
; 
23 
j 
24 
i 
25 
; 
26 
; 
27; 
28 ; 
29 
jU'u 


30 
Iew 


31 
; ••••• 


IN! 
rIALIZATION 
CONTROl. 
WORD 


USED TO CONFIGURE THE 8255 
AS fOLLOWS: 


PORT A - 
OOTPUT MODE 1 
PORT B - 
INPUT MODE0 (NOT USED) 
PORT CLOWER 
- 
OUTPUT 


The 
bit set/reset 
capability 
of the 8255 
is used to 
control 
the 
strobe 
to 
the 
printer 
and 
to enable/ 


disable interrupts 
from the 8255. 


32 
; 
SET/Rl::SET 
CONTROL wORDS 
33 ;••••• 


34 STBON 
EQU 
0000000 
1B 
; 
SET STROBE 


35 STOOP 
EQU 
0000סס oo8 
; 
RESET STROBE 
36 
;11 •••• 


37 
; 
8255 
ENABLE/DISABLE 
INTERRUPT 
CONTROL 
WORDS 


38 
;*tUu 


39 
IEN 
EQU 
00001101B 
; 
ENABLE 
INTERRUPTS 
1i0 ION 
EQU 
00001100B 
; 
DISABLE 
INTERRUPTS 
1i1 
; ••••• 


Device 
status, 
control 
block, 
and 
completion 
equates 
are shown 
below. 


112 
; 


113 
; ••••• 


411 LPBSY 
EQJ 
45 
INTRA 
EQJ 
46 
j ••••• 


41 
; 


48 
j ••••• 


49 CBST 
E 


50 
CBUf 
£QU 
51 
CBCC 
EQU 
52 
CBCT 
EQU 
53 
CBCMP 
EQU 
54 
;••••• 


55 ; 
56 ;••••• 
57 
ST\;D 
5d 
STE1 
59 ;••••• 


; 
STAruS 
BYTE 


; 
BUffER 
ADDRESS 


j 
CHARACTER COUNT 


; 
CHARACTER TRANSFERED COUNT 


; 
COMPLETION SERVICE 
ADDRESS 


There 
are two 
ongm 
statements 
in this 
program. 


The 
first 
origin 
at 
38 
hexadecimal 
is the 
entry 
point 
used 
when 
an interrupt 
is generated 
by the 
8255. 
A jump 
instruction 
to the printer 
interrupt 


routine 
is 
stored 
at 
that 
location. 
The 
second 
origin 
at 
3000 
hexadecimal 
is the 
address 
where 


the rest of the code will be located. 


60 
; 
RESTART 7 ENTRY POINT 
61 
;••••• 


62 
ORG 
0038H 


63 
JMP 
PINT 


61i 
.••••• 


65 
; 
PR<:X;RAMORIGIN 


66 
;••••• 


67 
ORG 
3000H 
68 
; ••••• 


An initialization 
subroutine 
issues 
the 
mode 
con- 
trol 
word 
to the 
8255 
control 
word 
register 
after 
reset of the device. The printer 
strobe 
must then be 


disabled. 


69 ; 
70 
; 


71 ; 
72 
; 
73; 
71i 
; ••••• 


15 INIT: 
16 
11 
18 
19 
80 
31 


INITIALIZATION 
ROUTINE 


A,H,L 
REGISTERS 
MODIfIED 


MVI 
A, IC\frI 
j 
GET MODE CONTROL WORD 
OUT 
C\frIR 
; 
OUTPUT TO CONTROL WORD REGISTER 


MVI 
A,STBQN 
; 
GET SET DATA STROBE CONTROL WORD 
OUT 
CWR 
; 
SET DATA STROBE (LO« 
TRUE SIGNAL) 
RE'!' 
; 
RETURN TO CALLER 


The 
command 
processor 
is 
started 
by 
the 
user 


routine 
through 
a subroutine 
call to PSTRT, 
with 


the 
address 
of the 
control 
block 
in the 
D and 
E 


registers. 
The 
command 
processor 
insures 
that 
an 


I/O operation 
is not already 
in progress, 
starts 
the 


I/O, enables 
interrupts, 
and returns 
to the caller so 


that other 
processing 
may proceed. 


The flowchart 
and listing for the command 
proces- 


sor are shown 
below. 


82 
83 
j ••••• 


84 
j 


85 ; 
86 
; 


81 ; 
88 ; 
89 ; 
go 
; 


91 
; 
92 
; 


93 ;••••• 
94 PSTRT: 
95 
96 
91 
98 
99 
100 
101 
102 
10J 
104 
105 
106 
101 
108 
109 
j ••••• 


110 ; 
111 
j ••••• 


112 PSTE: 
11J 
114 
115 


INPUTS: 
CONTROL BLOCK ADDRESS 
IN 
0 
AND E REGISTERS 


OUTPUTS: 
START 
I/O 
OR ERROR STATUS 
IN 
CONTROL BLOCK 


P!PRG+ 1 
; 
GET PRINT 
IN 
PROGRESS BLOCK ADDRESS 
A 
; 
SEE 
If 
ZERO (PRINT 
IN 
PRlX:RESS) 


; 
IF 
BLOCK 
ADDRESS 
NOT 
EQUAL 
10 
ZERO 
niEH 


; 
PRINT 
IN 
PROGRESS 
PSTE 
; 
IF 
YES - 
BRANCH TO ERROR 


PIPRG 
; 
SAVE 
COHTROL 
BLOCK 
ADDRESS 


H, CBCT 
; 
GET 
INDEX 
TO 
CT 


o 
; COI'\PlITE ADDRESS Of 
CT 


M,OOH 
; 
CLEAR 
CT 


PDATA 
; 
START 
I/O 


; 
ENABLE 
PROCESSOR 
INTERRUPTS 


; 
REnJRN 
TO CALLER 


Interrupt Processing. When the 8255 
generates 
an 


interrupt, 
the 
interrupt 
request 
is serviced 
by the 


8080A 
CPU. The CPU disables processor 
interrupts 


and 
then 
executes 
the instruction 
at location 
38 


hexadecimal, 
which 
is a jump 
to 
the 
interrupt 


service routine. 
The interrupt 
service routine 
saves 


the processor 
state and polls the 8255 to determine 
the 
source 
of the interrupt. 
Once the interrupting 


device is identified, 
the printer 
output 
data routine 


is called. 
After 
the entire 
buffer 
has been 
printed, 


the 
interrupt 
service 
routine 
passes control 
to the 


user-supplied 
completion 
routine. 
Before returning 


from 
the 
interrupt, 
the 
state 
of the 
processor 
is 


restored. 


There 
are a number 
of error conditions 
which may 


occur, 
such as an interrupt 
from a device that does 


not 
have an active 
control 
block, 
or an interrupt 


when 
polling 
establishes 
that 
no 
device 
requires 


service. 
Neither 
of these errors should 
occur, 
but if 


they 
do, the driver should 
perform 
in a consistent 


fashion. 
The 
recovery 
routines 
implemented 
to 


handle 
these 
interrupt 
error 
conditions 
are deter- 


mined 
by the environment 
of the particular 
appli- 
cation. 


The 
flowchart 
and listing 
for the printer 
interrupt 
service routine 
are shown below. 


116 
117 
; ••••• 


118 
; 


119 
; 
120 
j ••••• 


121 
PINT: 
122 
12J 
124 
125 
126 
;••••• 


PUSH 
PSW 
PUSH 
B 


PUSH 
0 


PUSH 
H 


SAVE 
PSW 
SAVE 
REGISTER 
PAIR 
BAND 
C 


SAVE 
REGISTER 
PAIR 
0 
AND 
E 


SAVE REGISTER 
PAIR 
HAND 
L 


121 
; 
128 
i••••• 
129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
1l!1 ; ••••• 


1112 
j 
1l!3 
j ••••• 


1l!l! 
PRTN: 
145 
146 
147 
148 
149 
150 
151 
; ••••• 


152 
; 
153 
; 
15l! 
; 
155 ; ••••• 
156 
PPOlL: 
157 
158 
; ••••• 
159 ; 
160 
; 
161 
; ••••• 


162 
PIER1: 
163 
164 


; 
GET STATUS Of 
DEVICE 


; 
SEE IF 
INT 


; 
NO -BRANCH TO POLL OTHER DEVICES 
If 
ANY 


; 
GET 8255 
INT 
DISABLE 
CONTROL WORD 


; 
DISABLE 
DEVICE 
INTERRUPTS 
; 
ENABLE 
PROCESSOR INTERRUPTS 


; 
GET CONTROL BLOCK ADDRESS 


; 
CLEAR A REG 


; 
SEE If 
PRINT 
IN 
PROGRESS 


i NO - 
BRANCH TO ERROR ROOfINE 


; 
PRINT 
DATA 


; 
RESTORE REGISTER 
PAIR 
HAND 
L 
; 
RESTORE REGISTER 
PAIR 
0 AND E 


; 
RESTORE REGISTER 
PAIR 
BAND 
C 


j 
RESTORE PSW AND A 


; 
ENABLE PROCESSOR INTERRUPTS 


; 
RETURN TO INTERRUP fED 
PROCESS 


The printer 
output 
data routine 
places 
a character 
in 
the 
output 
buffer 
of 
the 
8255. 
Data 
in the 


control 
block 
is used 
to 
direct 
the 
transfer 
of a 


character. 
A data 
strobe 
signal 
is then 
generated 
through 
the use of the port 
C bit set/reset 
feature. 


The 
flowchart 
and 
listing 
for the 
printer 
output 
data routine 
are shown 
below. 


165 
166 
j ••••• 


167 ; 
168 ; 
169 ; 
170 
; 
171 
; 


172 
j ••••• 


173 
PDATA: 


l7" 
175 
176 
177 
178 
179 
180 
181 
182 
183 
184 
185 
186 
187 
188 
189 
190 
191 
192 
193 
194 
195 
196 
197 
193 
199 
200 
201 


IN 
PORTe; 
GET STATUS Of 
DEVICE 


ANI 
LPBSY; 
SEE If 
BUSY (BUffER 
fULL) 


JZ 
POlO 
; 
If 
BUSY - 
BRANCH 


LXI 
H,CBCT; 
GEl' 
INDEX 
TO CT 


DAD 
D 
; 
COMPUTER ADDRESS Of 
CT 


t40V 
A,H 
j 
GET CT 


INR 
H 
j 
IHe 
CT 
DeX 
H 
; 
DEC TO CC 
CHP 
H 
; 
SEE If 
EQUAL 
JZ 
PCOHP; 
If 
EQUAL - 
OONE GO TELL 
USER 


LXI 
H,CBUf; 
GET INDEX 
TO BUffER 
ADDRESS 


DAD 
D 
; 
C(Xo1PUTEADDRESS Of 
BUfFER 
ADDRESS 


PUSH 
0 
; 
SAVE D AND E REGISTERS 


MOV 
E, M 
; 
GET LSB Of 
BUFFER ADDRESS 


INX 
H 
; 
INC 
TO NEXT BYTE 


MOV 
v, M 
; 
GET BUFFER MSB 


MVI 
H,OOH; 
CLEAR H REG 


MOV 
L,A 
; 
GET CT 


DAD 
0 
; 
COMPUTER CHARACrER 
ADDRESS 


MOV 
A,M 
; 
GET CHARACTER 
OUT 
PORTA 
; OUTPlIf 
CHARACTER TO PRINTER 
f14Vl 
A,STBOf 
; 
RESET DATA STROBE (l..OfI 
TImE 
SIGNAL) 


our 
C'o/R 
INR 
A 
; 
GENERATE SET CONTROL WORD 
OUT 
CwR 
; 
SET DATA STROBE 


POP 
D 
; 
RESTORE CONTROL BLOCK ADDRESS 


JMP 
PDATA; 
LOOP UNTIL 
BUSY 


If the printer 
is busy at the time the printer 
output 


routine 
is called, a printer 
busy routine 
is executed. 


The 
printer 
busy 
routine 
disables 
the 
processor 


interrupts, 
enables 
the 
8255 
interrupts 
and 
then 
enables 
the 
processor 
interrupts 
on its return 
to 


the caller. 


202 
203 
; •••••• 


204 
; 


205 
; ••••• 


206 
POlO: 


207 
20ll 
209 
210 


01 
; 
DISABLE 
INTERRUPTS 


MVI 
A,IEN 
; 
ENABLE DEVICE 
INTERRUPTS 


OUT 
CwR 
; 
SET 
INTERRUPT 
ENABLE 


RE! 
; 
RETIJRN TO CALLER 


When the printer 
output 
routine 
has exhausted 
the 


data 
from 
the buffer, 
a good status 
code 
is posted 


to the 
Llser. The 
command 
in progress 
flag is also 
cleared. 


211 
, 


212 
; 


213 
; •••••• 


214 
PCOHP: 


215 
216 
217 
218 
219 
220 


A,STGD 
<'OST 
A 
PIPRG+1 


; 
GET GOOD StATUS 
CODE 


; 
POST TO USER 


; 
CLEAR A REG 


; 
CLEAR C(IoIMAND IN 
PROORESS ADDRESS 


; 
RETURN TO CALLER 


The 
post 
to user 
completion 
routine 
obtains 
the 
completion 
address 
from 
the device 
control 
block 


and passes control 
to the user routine. 


INPUTS: 
STATUS CODE IN 
A REG 
CONTROL BLOCK ADDRESS IN 
D AND E REG 
OUTPUTS: 
PASSES CONTROL TO USER a>1PLETION 
ADDRfS 
SPECIFIED 
IN 
CONTROL BLOCK 


WITH 
CONTROL BLOCK ADDRESS IN 
D AND E RE 


A,H,L,B,C 
REG MODIFIED 


235 
POST: 


236 
237 
236 
239 
240 
24' 
242 
243 
244 
245 
246 
;••••• 


247 
; 


248 
; ••••• 


249 
ORG 
250 
PIPRG: 
OW 


25' 
252 
253 
j ••••• 


254 
; 


255 
j ••••• 


256 


H,CBCMP 
; 
GET INDEX 
TO COOPLETION 
ADDRESS 
D 
; 
COMPUTE ADDRESS 
C, M 
; 
GET LSB Of 
COOPLETION 
ADDRESS 


H 
; 
INC 
TO NEXT 
BtTE 
B,M 
; 
GET MSB OF' CCX'lPLETION 
ADDRESS 
B 
; 
PUSH ADDRESS ON STACK 


; 
PASS CONTROL TO USER ROUTINE 


; 
IN 
PROORESS CONTROL BLOCK ADDRESS 


; 
IF' 
DATA = 0 
NO CONTROL BLOCK 
IN 
PROGRESS 


; 
IF 
DATA <> 0 CONTROL BLOCK IN 
PROORESS 


SUMMARY /CONCLUSIONS 


The 
iSBC 80/ I OA has the 
capability 
to function 
in 
the 
capacity 
of 
a 
peripheral 
processor 
and/or 
a 


device 
controller. 
This 
capability 
is 
provided 
in 


part 
by 
the 
interrupt 
support 
logic 
accompanying 


the 
parallel 
I/O 
ports. 
This 
application 
example 


shows 
how 
the 
iSBC 80/l0A 
requires 
only an inter- 


connect 
to the device to be controlled. 


i$BC aO/l0A 
CENTRONICS 
306 
,------, 
7437 
I 
PA, 
I 
(Jl·33) 


I 


GROUP;' 
I 


(Jl·35l 


PA. 


8255 
I 
(Jl·37) 


I 
PAS 


I 
(J1.39) 


PA4 
I 
PORT 1 (A) 
DATA 
lJl·47) 


I 
PA3 
I 
(Jl·45) 


I 
PA, 


I 
(J1·41) 


PA, 
I 
(J1-43) 


I 
PAD 
I 
I 
I 
7437 


I 


(Jl·25) 


PCo 
DATA 
STROBE 


I 
VCC 
I 
I 
PORT 3 (C) 


'K 
I 
(Jl·23l 


I 
PC. 
ACKNLG 


I 


ACKA 
I 
L _____ 
J 


CONCLUSION 


The 
purpose 
of this 
application 
note 
has been 
to 


expose 
the reader 
to a broad spectrum 
of potential 


applications 
of the Intel 
iSBC 80/1 OA and System 


80/1 0 products. 
Applications 
have been 
presented 


in the 
areas 
of 
instrumentation, 
communication, 


process 
control 
and I/O device 
control. 
The exam- 


ples were 
limited 
to short 
problems 
that 
could 
be 


completely 
described. 


Intel's 
PL/M-80 
and 
8080 
Macro 
Assembly 
Lan- 


guage 
were 
both 
used in the examples. 
Instead 
of 


using 
only 
assembly 
language, 
it 
was 
felt 
that 


PL/M-80 
should 
also 
be 
shown. 
Coding 
in 
an 


algorithmic 
language 
is generally 
more natural 
than 


assembly 
language 
and provides 
these 
added 
bene- 


fits: 
reduced 
program 
development 
time and cost, 
improved 
product 
reliability, 
and 
easier 
program 
maintenance. 


While 
the 
task 
of 
actually 
configuring 
the 
SBC 


80/1 0 for the applications 
has not been described 


in this note, 
detailed 
instructions 
are contained 
in 


the tables 
of Chapter 
4 in theiSBC 
80/10 
and iSBC 
80/l0A 
Single 
Board 
Computer 
Hardware 
Refer- 


ence Manual. 


The 
Intel 
iSBC 80/ IOA has been 
designed 
to pro- 


vide 
users 
with 
subsystems 
that 
have 
processing 


power, 
memory 
storage, 
parallel 
and 
serial 
pro- 


grammable 
I/O 
interfaces. 
A design 
goal 
of 
the 


iSBC 
80/ I OA was 
to 
minimize 
the 
requirements 


for customized 
interface 
hardware 
in user applica- 


tions. 
This 
application 
note 
has demonstrated 
the 


achievement 
of 
this 
goal. 
The 
net 
effect 
is 
to 


reduce 
the 
number 
of 
tedious 
design 
tasks, 
thus 


allowing 
the 
systems 
designer 
to 
concentrate 
on 


systems 
integration 
and 
other 
problems 
unique 


to his job. 
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attributed 
to the design of the Intel MULTIBUS 
system bus. The bus structure provides a common 
element 
for communication 
between 
a wide 
variety 
of system modules which include: 
Single 


Board 
Computers, 
memory, 
digital, 
and analog 
110 expansion 
boards, and peripheral 
controllers. 


The purpose of this application 
note is to help you 
develop a working knowledge ofthe Intel MULTI- 
BUS specification. 
This knowledge is essential for 
configuring 
a system 
containing 
multiple 
mod- 
ules. 
Another 
purpose is to provide you with the 
information 
necessary 
to design a bus interface for 


a slave module. One of the tools that will be used to 
achieve this goal is the complete description 
of a 
MULTI BUS slave design example. Other portions 
of this 
application 
note 
provide 
an in depth 
examination 
of the bus signals, operating charac- 
teristics, 
and bus interface 
circuits. 


This application 
note was originally 
written 
in 
1977. 
Since 1977, the MULTIBUS 
specification 
has been significantly 
expanded 
to cover opera- 
tion with both 8 and 16-bit system modules and 
with an auxiliary 
power bus. 
This application 
note 
now 
contains 
information 
on these 
new 
MULTIBUS 
specification 
features. 


In addition, 
a detailed MULTIBUS 
specification 
has also been published 
which provides the user 
with further 
information 
concerning 
MULTIBUS 
interfacing. 
The MULTIBUS 
specification 
and 
other useful documents 
are listed in the overleaf of 
this note under Related Intel Publications. 


II. MULTIBUSTMSYSTEM BUS 
DESCRIPTION 


The Intel MULTIBUS signal lines can be grouped 
in the following categories: 
20 address 
lines, 16 


bidirectional 
data 
lines, 
8 multilevel 
interrupt 
lines, and several bus control, timing and power 
supply 
lines. 
The address 
and 
data 
lines 
are 
driven by three-state 
devices, while the interrupt 
and 
some other 
control 
lines are open-collector 
driven. 


Modules that use the MULTIBUS system bus have 
a master-slave 
relationship. 
A bus master module 
can drive the command 
and address lines: it call 


control the bus. 
A Single Board Computer is an 
example 
of a bus master. 
A bus slave cannot 


bus masters 
and slaves. 


Notice that 
a system may have a number of bus 


masters. 
Bus arbitration 
results when more than 


one master requests control of the bus at the same 
time. A bus clock is usually provided by one ofthe 
bus masters 
and may be derived independently 


from the processor clock. The bus clock provides a 
timing 
reference 
for resolving 
bus 
contention 
among multiple requests 
from bus masters. 
For 


example, a processor and a DMA (direct memory 
access) module may both request 
control of the 


bus. This feature allows different speed masters to 
share resources on the same bus. Actual transfers 
via 
the bus, 
however, 
proceed 
asynchronously 


with respect to the bus clock. Thus, the transfer 
speed 
is dependent 
on the 
transmitting 
and 
receiving 
devices only. 
The bus design prevents 


slow master 
modules from being handicapped 
in 
their attempts 
to gain control of the bus, but does 


not restrict the speed at which faster modules can 
transfer data via the same bus. Once a bus request 
is granted, 
single or multiple read/write 
transfers 
can proceed. The most obvious applications 
for the 


master-slave 
capabilities 
of the bus 
are multi- 
processor 
configurations 
and 
high-speed 
direct- 
memory-access 
(DMA) operations. 
However, the 


master-slave 
capabilities 
of the bus are by no 


means limited to these two applications. 


This section defines the signal lines that comprise 
the Intel MULTIBUS 
system bus. 
These signals 
are contained 
on either the PI or P2 connector of 


boards 
compatible 
with the MULTIBUS 
specifi- 


cation. 
The PI signal 
lines contain the address 


data, 
bus control, 
bus exchange, 
interrupt 
and 


power supply lines. The P2 signal lines contain the 
optional 
auxiliary 
signal lines. 
Most signals 
on 
the bus are active-low. For example, a low level on 
a control signal on the bus indicates active, while a 
low level on an address or data signal on the bus 
represents 
logic "I" value. 


NOTE 


In this application 
note, a signal 
will be 


designated 
active-low by placing a slash (I) 


after the mnemonic 
for the signal. 


Appendix A contains 
a pin assignment 
list of the 


following signals: 


Initialization 
signal; resets the entire system to 
a known internal 
state. 
INIT I may be driven by 


one of the bus masters 
or by an external 
source 
such as a front panel reset switch. 


20 address 
lines; used to transmit 
the address of 


the memory location or 110 port to be accessed. 
The lines are labeled ADROI through 
ADR9/, 
ADRAI 
through 
ADRFI 
and ADR101 through 


ADR13/. 
ADR131 is the most significant 
bit. 
8-bit masters 
use 
16 address 
lines 
(ADROI - 


ADRF I) for memory addressing 
and 8 address 


lines (ADROI - ADR7/) 
for 110 port selection. 
16-bit masters 
use all twenty 
address 
lines for 


memory 
addressing 
and 
12 address 
lines 
(ADROI - ADRB/) for 110 port selection. 
Thus, 
8-bit masters 
may address 64K bytes of memory 
and 256 110 devices while 16-bit masters 
may 
address 
1 megabyte 
of memory 
and 4096 110 


devices. 
(The 8086 CPU actually 
permits 
16 


address 
bits to be used to specify 110 devices, 
the MULTIBUS 
specification, 
however, states 


that 
only the low order 12 address 
bits can be 
used to specify 110 ports.) 
In a 16-bit system, 
the ADROI line is used to indicate whether a low 
(even) byte or a high (odd) byte of memory or 
110 space is being accessed in a word oriented 
memory or 110 device. 


Byte 
High 
Enable; 
the 
address 
control 
line 
which is used to specify that data will be trans- 
ferred on the high byte (DAT81 - DATF/) 
of the 
MULTIBUS 
data 
lines. 
With 
current 
iSBC 
boards, 
this signal 
effectively 
specifies that 
a 


word (two byte) transfer 
is to be performed. 
This 


signal is used only in systems which incorporate 
sixteen bit memory or 110 modules. 


Inhibit 
RAM 
signal; 
prevents 
RAM memory 
devices from responding 
to the memory address 


on the system 
address 
bus. 
INH11 effectively 
allows ROM memory devices to override RAM 
devices 
when 
ROM 
and 
RAM 
memory 
are 


assigned 
the same memory addresses. 
INHl/ 


may also be used to allow memory mapped 110 
devices to override RAM memory. 


INH21 


Inhibit 
ROM 
signal; 
prevents 
ROM memory 


devices from responding 
to the memory address 
on the system 
address 
bus. 
INH21 effectively 


allows 
auxiliary 
ROM (e.g., a bootstrap 
pro- 


gram) to override ROM devices when ROM and 
auxiliary 
ROM memory are assigned 
the same 


memory addresses. 
INH21 may also be used to 
allow memory mapped 
110 devices to override 


ROM memory. 


16 bidirectional 
data lines; used to transmit 
or 


receive information 
to or from a memory loca- 
tion or 110 port. DATF I being the most signifi- 
cant bit. 
In 8-bit systems, 
only lines DATOI - 


DAT7I are used (DAT7I being the most signi- 
ficant bit). In 16-bit systems, either 8 or 16 lines 
may be used for data transmission. 


BCLKI 


Bus 
clock; the negative 
edge (high 
to low) of 
BCLKI 
is used to synchronize 
bus priority 
re- 
solution circuits. 
BCLKI is asynchronous 
to the 
CPU clock. It has a 100 ns minimum 
period and 
a 35')10to 65%duty cycle. BCLKI may be slowed, 
stopped, or single stepped for debugging. 


Constant 
clock; a bus signal 
which provides 
a 
clock signal 
of constant 
frequency 
for unspeci- 


fied general 
use by modules on the system bus. 
CCLKI 
has a minimum 
period of 100 ns and a 
35% to 65% duty cycle. 


Bus priority 
in signal; indicates 
to a particular 


master 
module that 
no higher 
priority 
module 


is requesting 
use of the system bus. 
BPRNI is 


synchronized 
with BCLKI. 
This signal 
is not 


bused on the backplane. 


Bus priority 
out signal; used with serial (daisy 


chain) bus priority resolution schemes. 
BPRO/ 


is passed 
to the BPRN/ 
input 
of the master 
module with the next lower bus priority. BPRO/ 
is synchronized 
with BCLK/. 
This signal is not 


bused on the backplane. 


Bus 
busy 
signal; 
an open collector line driven 


by the bus master currently in control to indicate 
that the bus is currently in use. BUSY/prevents 
all other master 
modules from gaining 
control 


ofthe bus. BUSY/is 
synchronized 
with BCLK/. 


Bus 
request 
signal; 
used with 
a parallel 
bus 


priority 
network 
to indicate 
that 
a particular 


master 
module requires 
use of the bus for one 


or more data transfers. 
BREQ/ is synchronized 


with BCLK/. 
This signal is not bused on the 


backplane. 


Common 
bus 
request; 
an 
open-collector 
line 


which 
is driven 
by all potential 
bus masters 


and is used to inform the current 
bus master 


that 
another 
master wishes to use the bus. 
If 


CBRQ/ 
is high, it indicates 
to the bus master 


that no other master is requesting 
the bus, and 


therefore, the present bus master can retain the 
bus. 
This saves the bus exchange overhead for 


the current master. 


A bus 
master 
provides 
separate 
read/write 


command 
signals 
for memory and I/O devices: 
MRDC/, 
MWTC/, 
lORC/ 
and 
lOWC/, 
as ex- 


plained 
below. 
When a read/write 
command 
is 


active, the address signals must be stabilized at all 
slaves on the bus. 
For this reason, the protocol 


requires 
that 
a bus master 
must issue address 


signals (and data signals for a write operation) at 
least 50 ns ahead of issuing a read/write 
command 


to the bus, initiating 
the data transfer. 
The bus 


master must keep address signals unchanged 
until 


at least 
50 ns after the read/write 
command 
is 
turned off, terminating 
the data transfer. 


A bus slave must provide an acknowledge signal to 


the bus master 
in response 
to a read 
or write 


command 
signal. 


MRDC/ 


Memory 
read 
command; 
indicates 
that 
the 


address 
of a memory location has been placed 


on the system address 
lines and specifies that 


the 
contents 
(8 or 16 bits) 
of the 
addressed 


location are to be read and placed on the system 
data bus. MRDC/ is asynchronous 
with respect 


to BCLK/. 


Memory 
write 
command; 
indicates 
that 
the 


address 
of a memory location has been placed 


on the system address lines and that data (8 or 
16 bits) has been placed on the system data bus. 
MWTC/ specifies that the data is to be written 
into the addressed memory location. 
MWTC/ is 


asynchronous 
with respect to BCLK/. 


I/O 
read command; 
indicates 
that the address 


of an input port has been placed on the system 
address bus and that the data (8 or 16 bits) at 
that input port is to be read and placed on the 
system data bus. 
10RC/ is asynchronous 
with 


respect to BCLK/. 


I/O write command; 
indicates 
that the address 


of an output port has been placed on the system 
address bus and that the contents of the system 
data bus (8 or 16 bits) are to be output to the 
address 
port. 
10WC/ 
is asynchronous 
with 


respect to BCLK/. 


Transfer 
acknowledge 
signal; 
the required 


response 
of a slave board which indicates 
that 


the 
specified 
read/write 
operation 
has 
been 


completed. 
That is, data has been placed on, or 


accepted 
from, 
the 
system 
data 
bus lines. 


XACK/ is asynchronous 
with respect to BCLK/. 


used with 
a parallel 
interrupt 
resolution 
net- 


work. 
INTOI 
has the highest 
priority, 
while 


INT7 I has 
lowest 
priority. 
Interrupt 
lines 
should be driven with open collector drivers. 


Interrupt 
acknowledge; 
an interrupt 
acknowl- 


edge line (INTA/), 
driven by the bus master, 
requests 
the transfer 
of interrupt 
information 


onto the bus from slave priority interrupt 
con- 


trollers (8259s or 8259As). The specific informa- 
tion 
timed 
onto 
the 
bus 
depends 
upon 
the 
implementation 
of the interrupt 
scheme. 
In 


general, 
the leading 
edge of INT AI indicates 


that the address bus is active while the trailing 
edge indicates 
that data is present on the data 
lines. 


MULTIBUS 
P2 
Signal 
Lines 
- 
The signals 
contained 
on the MULTIBUS 
P2 auxiliary 
con- 
nector 
are 
used 
primarily 
by optional 
power 
back-up 
circuitry 
for memory 
protection. 
P2 
signals 
are 
not 
bused 
on the 
backplane, 
and 


therefore, 
require 
a separate 
connector 
for each 


board using the P2 signals. 
Present iSBC boards 
have a slot in the card edge and should be used 
with a keyed P2 edge connector. 
Use of the P2 
signal lines is optional. 


AC Low; this signal 
generated 
by the power 
supply 
goes high when the AC line voltage 
drops below a certain voltage (e.g., 103v AC in 
115v AC line voltage systems) indicating 
D.C. 
power will fail in 3 msec. ACLO goes low when 
all D.C. voltages return 
to approximately 
95% 


of the regulated value. This line must be pulled 
up by the optional standby 
power source, if one 
is used. 


Power fail interrupt; this signal interrupts 
the 
processor 
when 
a power failure 
occurs, it is 


driven by external 
power fail circuitry. 


Power fail sense; this line is the output 
of a 
latch which indicates 
that a power failure has 
occurred. 
It is reset by PFSR/. 
The power fail 


sense latch 
is part 
of external 
power fail cir- 


cuitry 
and 
must 
be powered 
by the standby 


power source. 


Power fail sense reset; this line is used to reset 
the power fail sense latch (PFSN/). 


Memory 
protect; 
prevents 
memory 
operation 


during 
period of uncertain 
DC power, by in- 


hibiting 
memory requests. 
MPROI 
is driven 


by external power fail circuitry. 


ALE 


Address 
latch enable; generated 
by the CPU 


(8085 or 8086) to provide an auxiliary 
address 


latch. 


Auxiliary 
Reset; this externally 
generated 
sig- 


nal initiates 
a power-up sequence. 


Bus 
master 
wait state; this 
signal 
indicates 


that the processor is in a wait state. 


Reserved 
- 
Several 
PI and P2 connector 
bus 


pins are unused. 
However, they should be regard· 


ed as reserved 
for dedicated 
use in future Intel 


products. 


Power 
Supplies 
- 
The power supply bus pins 


are detailed 
in Appendix 
A which contains 
the 


pin 
assignment 
of signals 
on the MULTIBUS 


backplane. 


It is the 
designer's 
responsibility 
to provide 
adequate 
bulk decoupling on the board to avoid 


current surges on the power supply lines. It is also 
recommended 
that 
you provide high 
frequency 


decoupling 
for the logic on your board. 
Values of 
22uF for +5v and +12v pins and 10uF for -5v and 
-12v pins are typical on iSBC boards. 


Beyond the definition 
of the MULTIBUS 
signals 
themselves, 
it is important 
to examine 
the 


operating 
characteristics 
of the 
bus. 
The AC 
requirements 
outline the timing of the bus signals 


and in particular, 
define the relationships 
between 
the various bus signals. 
On the other hand, the DC 


requirements 
specify 
the 
bus driver 
character- 


istics, maximum 
bus loading 
per board, and the 
pull-upl down resistors. 


The 
AC requirements 
are best presented 
by a 


discussion 
of the relevant 
timing 
diagrams. 
Appendix 
B contains 
a list of the MULTIBUS 
timing specifications. 
The following sections will 


discuss 
data 
transfers, 
inhibit 
operations, 
inter- 
rupt operations, 
MULTIBUS 
multi-master 
opera- 


tion and power fail considerations. 


Data 
Transfers 
- Data transfers 
on the MULTI- 


BUS system 
bus occur with a maximum 
band- 


width of 5 MHz for single or multiple read/write 
transfers. 
Due to bus arbitration 
and memory 
access time, a typical 
maximum 
transfer 
rate is 


often on the order of 2 MHz. 


Read Data 


Figure 
1 shows 
the read 
operation 
AC timing 
diagram. 
The address must be stable (tAS) for a 
minimum 
of 50 ns before command 
(IORCI 
or 
MRDC/). 
This time is typically 
used by the bus 
interface 
to decode the alidress and thus provide 
the required 
device selects. 
The device selects 
establish 
the data 
paths 
on the user system 
in 
anticipation 
of the 
strobe 
signal 
(command) 
which will follow. The minimum command pulse 
width is 100 ns. The address must remain stable 
for at least 50 ns following the command 
(tAH). 


Valid data should not be driven onto the bus prior 
to command, 
and must not be removed until the 
command is cleared. The XACKI 
signal, which is 
a response 
indicating 
the 
specified 
read/write 
operation 
has been completed, 
must coincide or 
follow both the read access and valid data (tDXL)' 
XACKI 
must be held un til the command is cleared 


(tXAH)· 
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Write Data 


The write operation 
AC timing diagram 
is shown 


in Figure 2. During 
a write data transfer, 
valid 


data 
must 
be presented 
simultaneously 
with 
a 


stable 
address. 
Thus, the write data setup time 


(tDS) has the same requirement 
as the address 


setup time (tAS). The requirement 
for stable data 


both 
before 
and 
after 
command 
(IOWCI 
or 


MWTC/) 
enables 
the bus interface 
circuitry 
to 


latch data on either the leading or trailing 
edge of 
command. 
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A 16-bit master may transfer 
data on the MULTI- 


BUS 
data 
lines 
using 
8-bit 
or 
16-bit 
paths 


depending 
on whether 
a byte or word (2 byte) 


operation 
has been specified. 
(A word transfer 
specified with an odd 110 or memory address will 
actually be executed as two single byte transfers.) 
An 8-bit master 
may only perform byte transfers 


on the MULTIBUS 
data lines DATOI 
- DAT7I. 


In 
order 
to maintain 
compatibility 
with 
older 


8-bit masters 
and slaves, a byte swapping 
buffer 


is included 
in all new 16-bit masters 
and 16-bit 


slaves. 
In the iSBC product line, all byte transfers 


will take place on the low 8 data lines DATOI 
- 


DAT7 I. 
Figure 3 contains 
a example of 8/16-bit 
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Figure 
4. 8/16-Bit 
Device 
Transfer 
Operation 
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data 
driver 
logic for 16-bit master 
and 
slave 
systems. 
In the 8/16-bit system, there are three 
sets 
of buffers; 
the 
lower 
byte 
buffer 
which 


accesses 
DATOI - DAT7I, the upper byte buffer 
which 
accesses 
DAT81 - DATF/, 
and the swap 
byte buffer which accesses the MULTIBUS 
data 
lines 
DATOI 
- DAT7I 
and 
transfers 
the 
data 
tolfrom 
the on-board data bus lines D8 - DF. 


Figure 4 summarizes 
the 8 and 16-bit data paths 
used for three types of MULTI BUS transfers. 
Two 
signals 
control the data transfers. 


Byte High Enable (BHEN I) active indicates 
that 
the 
bus is operating 
in sixteen 
bit mode, and 
Address Bit 0 (ADRO/) defines an even or odd byte 
transfer 
address. 


On the first type of transfer, 
BHENI 
is inactive, 
and ADROI is inactive 
indicating 
the transfer 
of 
an even eight bit byte. 
The transfer 
takes place 
across data lines DATOI - DAT7I. 


On the second type oftransfer, 
BHEN I is inactive, 
and ADROI is active indicating 
the transfer 
of a 
high (odd) byte. 
On this type of transfer, 
the odd 
(high) byte is transferred 
through 
the Swap Byte 
Buffer to DATOI - DAT7I. 
This makes eight bit 
and sixteen bit systems compatible. 


BUFFERED 


BHENI 


ADRO 


UPPER 
BYTE 
BUFFER 


DEVICE 
BYTE 
TRANSFERRED 


MULTIBUS 
TRANSFER 
DATA 
PATH 


The 
third 
type 
of transfer 
is a 16 bit 
(word) 


transfer. 
This 
is indicated 
by BHENI 
being 


active, and ADRO/ being inactive. 
On this type of 
transfer, 
the 
low 
(even) 
byte 
is transferred 
on 


DATal 
- DAT7I 
and 
the 
high 
(odd) 
byte 
is 
transferred 
on DAT81 - DATF/. 


Note that 
the condition 
when 
both BHENI 
and 


ADROI 
are active 
is not used with present 
iSBC 
boards. 
This condition 
could be used to transfer 
a 
high 
odd byte of data 
on DAT81 - DATF/, 
thus 


eliminating 
the 
need 
for the 
swap 
byte 
buffer. 


However, this is not a recommended 
transfer 
type, 
because 
it eliminates 
the capability 
of communi- 


cating 
with 8-bit modules. 


Inhibit 
Operations 
- 
Bus inhibit 
operations 
are 


required by certain 
bootstrap 
and memory mapped 


110 configurations. 
The purpose 
of the inhibit 


operation 
is to allow a combination 
of RAM, ROM, 


or memory 
mapped 
110 
to occupy 
the 
same 


memory 
address 
space. 
In the case of a bootstrap, 


it may be desirable 
to have both ROM and RAM 
memory 
occupy the same address 
space, selecting 


ROM instead 
of RAM for low order memory 
only 


when the system is reset. A system designed to use 


memory 
mapped 
110, which 
has actual 
memory 


occupying 
the 
memory 
mapped 
110 
address 


space, may need to inhibit 
RAM or ROM memory 


to perform 
its functions. 


There are two essential 
requirements 
for a success- 
ful inhibit 
operation. 
The first is that the inhibit 


signal must be asserted 
as soon as possible, within 


a maximum 
of 100 ns (tCI), after stable 
address. 


The second 
requirement 
for a successful 
inhibit 


operation 
is that the acknowledge 
must be delayed 


(tXACKB) 
to allow 
the 
inhibited 
slave 
to ter- 


minate 
any 
irreversible 
timing 
operations 
in- 


itiated 
by detection 
of a valid command 
prior to its 


inhibit. 


This situation 
may arise because 
a command 
can 


be asserted 
within 50 ns after stable address 
(tAS) 


and yet inhibit 
is not required 
until 
100 ns (tID) 


after stable 
address. 
The acknowledge 
delay time 


(tXACKB) 
is a function 
of the cycle time of the 


inhibited 
slave memory. 
Inhibiting 
the iSBC 016 


RAM board, 
for example, 
requires 
a minimum 
of 


1.5 usee. 
Less time is typically 
needed to inhibit 


other memory modules. 
For example, 
the iSBC 104 


board 
requires 
475 ns. 
Figure 
5 depicts 
a situation 
in which 
both RAM 
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LOCAL 


SELECT I 


and 
PROM 
memory 
have 
the 
same 
memory 


addresses. 
In this 
case, PROM inhibits 
RAM, 
producing 
the effect of PROM overriding 
RAM. 
After address 
is stable, local selects are generated 


for both the PROM and the RAM. The PROM local 
select 
produces 
the 
INHII 
signal 
which 
then 


removes the RAM local select and its driver enable. 
Because the slave RAM has been inhibited 
after it 


had already 
begun its cycle, the PROM XACKI 
must be delayed (tXACKB) 
until after the latest 


possible 
acknowledgement 
from 
the 
RAM 


(tXACKA)· 


Interrupt 
Operations 
- 
The MULTIBUS 
inter- 


rupt lines INTOI - INT71 are used by a MULTI- 
BUS master to receive interrupts 
from bus slaves, 
other bus masters 
or external 
logic such as power 


fail logic. A bus master may also contain internal 
interrupt 
sources 
which 
do not require 
the bus 


interrupt 
lines to interrupt 
the master. 
There are 
two interrupt 
implementation 
schemes 
used by 
bus interrupts, 
Non Bus Vectored Interrupts 
and 


Bus 
Vectored 
Interrupts. 
Non 
Bus 
Vectored 


Interrupts 
do not convey interrupt 
vector address 
information 
on the bus. 
Bus Vectored Interrupts 
are interrupts 
from slave Priority 
Interrupt 
Con- 


trollers 
(PICs) which do convey interrupt 
vector 


Non Bus Vectored Interrupts 


Non Bus Vectored Interrupts 
are those interrupts 
whose interrupt 
vector address is generated 
by the 
bus master 
and 
do not require 
the MULTIBUS 
address 
lines for transfer 
of the interrupt 
vector 
address. 
The interrupt 
vector address is generated 
by the 
interrupt 
controller 
on the 
master 
and 
transferred 
to the processor over the local bus. The 


source of the interrupt 
can be on the master module 
or on other bus modules, 
in which 
case the bus 


modules 
use the MULTIBUS 
interrupt 
request 
lines (lNTOI - INT7/) 
to generate 
their interrupt 
requests 
to the bus master. 
When an interrupt 
request line is activated, the bus master performs it 
own interrupt 
operation 
and processes 
the inter- 
rupt. 
Figure 
6 shows 
an example 
of Non Bus 
Vectored Interrupt 
implementation. 


Bus Vectored Interrupts 


Bus Vectored Interrupts 
(Figure 7) are those inter- 
rupts which transfer 
the interrupt 
vector address 
along 
the 
MULTIBUS 
address 
lines 
from 
the 
sla ve to the bus master using the INT AI command 
signal for synchronization. 
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When an interrupt 
request from the MULTIBUS 


interrupt 
lines INTOI -INT7 I occurs, the interrupt 


control 
logic 
on the bus master 
interrupts 
its 


processor. 
The 
processor 
on the 
bus 
master 


generates 
an INTAI 
command 
which freezes the 


state 
of the interrupt 
logic on the MULTIBUS 


slaves for priority resolution. 
The bus master also 


locks (retains 
the 
bus between 
bus cycles) the 


MULTIBUS 
control 
lines 
to guarantee 
itself 


consecutive 
bus cycles. 
After the first INTAI 
command, the bus master's 
interrupt 
control logic 


puts 
an 
interrupt 
code on to the MULTIBUS 


address lines ADR81 -ADRAI. Theinterruptcode 
is the address 
of the highest 
priority active inter- 


rupt request line. At this point in the Bus Vectored 


Interrupt 
procedure, two different sequences could 


take 
place. 
The difference 
occurs, because 
the 


MULTIBUS 
specification 
can 
support 
masters 


which 
generate 
one additional 
INTAI 
(8086 


masters) 
or two additional 
INTA/s 
(8080A and 


8085 masters). 


If the bus master generates 
one additional 
INT AI, 


this second INTAI causes the bus slave interrupt 
control logic to transmit 
an interrupt 
vector 8-bit 


pointer on the MULTIBUS 
data lines. The vector 


pointer is used by the bus master to determine the 
memory address 
of the interrupt 
service routine. 


If the 
bus 
master 
generates 
two 
additional 


INTA/s, 
these two INTAI 
commands 
allow the 


The MUL TIBUS 
specification 
provides for only 


one type of Bus Vectored Interrupt 
operation 
in a 


given system. 
Slave boards which have an 8259 


interrupt 
controller 
are only capable of 3 INTAI 


operation 
(2 additional 
INTA/s 
after 
the first 


INTA/). 
Slave boards 
with the 8259A interrupt 


controller 
are 
capable 
of either 
2 INTAI 
or 3 


INTAI 
operation. 
All slave boards 
in a given 


system must operate in the same way (2 INTA/s 
or 


3 INTA/s) 
if Bus Vectored Interrupts 
are to be 


used. 
However, 
the MULTIBUS 
specification 


does provide for Bus Vectored Interrupts 
and Non 


Bus Vectored Interrupts 
in the same system. 


MULTIBUS 
Multi-Master 
Operation 
- 
The 


MULTI BUS system bus can accommodate 
several 


bus masters 
on the same system, each one taking 


control of the bus as it needs to affect data trans- 
fers. The bus masters request bus control through 
a bus exchange 
sequence. 


Two bus exchange 
priority resolution 
techniques 


are discussed, 
a serial technique 
and a parallel 


technique. 
Figures 
8 and 9 illustrate 
these two 


techniques. 
The 
bus exchange 
operation 
dis- 


cussed later is the same for both techniques. 


Serial Priority Technique 


Serial priority 
resolution 
is accomplished 
with a 
daisy chain technique 
(see Figure 8). The priority 
input 
(BPRN/) 
of the highest 
priority 
master 
is 
tied to ground. 
The priority output (BPRO/) 
of the 


request will set its BPROI 
signal high to the next 


lower priority master. 
Any master 
seeing a high 


signal on its BPRNI 
line will sets its BPROI 
line 


high, thus passing 
down priority 
information 
to 


lower priority 
masters. 
In this implementation, 


the bus request line (BREQ/) 
is not used outside of 
the 
individual 
masters. 
A limited 
number 
of 


masters 
can be accommodated 
by this technique, 


due to gate delays through the daisy chain. 
Using 


the current 
Intel MULTIBUS 
controller 
chip on 
the master boards up to 3 masters 
may be accom- 
modated 
if a BCLKI 
period of 100 ns is used. 
If 


more bus masters are required, either BCLKI 
must 


be slowed or a parallel 
priority technique 
used. 


Parallel 
Priority Technique 


In the parallel 
priority 
technique, 
the priority 
is 


resolved in a priority resolution 
circuit in which 


the highest priority BREQI 
input is encoded with 
a priority encoder chip (74148). This coded value is 
then decoded with a priority decoder chip (74S138) 
to activate 
the appropriate 
BPRNI 
line. 
The 


BPROI 
lines are not used in the parallel 
priority 


scheme. 
However, 
since the MUL TIBUS 
back- 


plane contains 
a trace from the BPRNI 
signal of 
one card slot to the BPROI 
signal of the adjacent 


lower card slot, the BPROI 
must be disconnected 


from the bus on the board or the backplane 
trace 


must be cut. 
A practical 
limit of sixteen masters 
can be accommodated 
using the parallel 
priority 


technique 
due to physical 
bus length limitations. 


Figure 
9 contains 
the schematic 
for a typical 


parallel resolution network. 
Note that the parallel 


priority 
resolution 
network 
must 
be externally 


supplied. 


MUL TIBUS 
Exchange 
Operation 
- 
A timing 


diagram 
for the MULTIBUS 
exchange 
operation 


is shown 
in Figure 
10. 
This 
implementation 


example 
uses a parallel 
resolution 
scheme, how- 


ever, the timing 
would be basically 
the same for 


the serial resolution 
scheme. 


In this example, 
master 
A has been assigned 
a 
lower priority 
than master 
B. The bus exchange 


occurs because master 
B generates 
a bus request 


during 
a time when master 
A has control of the 


bus. 


The 
exchange 
process 
begins 
when 
master 
B 


req uires the bus to access some resource such as an 
I/O or memory module while master A controls the 
bus. 
This internal 
request 
is synchronized 
with 


the 
trailing 
edge 
(high 
to low) of BCLKI 
to 


generate 
a bus request (BREQ/). 
The bus priority 


resolution 
circuit changes the BPRNI 
signal from 


active 
(low) to inactive 
(high) for master 
A and 


from inactive 
to active 
for master 
B. 
Master A 


must first complete 
the current 
bus command 
if 


one is in operation. 
After master A completes the 


command, 
it sets 
BUSY I inactive 
on the 
next 


trailing 
edge of BCLK/. 
This allows the actual bus 


exchange 
to occur, because 
master 
A has relin- 


quished control of the bus, and master B has been 
granted 
its BpRNI. 
During this time, the drivers 


for master 
A are disabled. 
Master 
B must take 


control 
of the bus with the next trailing 
edge of 


BCLKI 
to complete the bus exchange. 
Master 
B 


takes control by activating 
BUSY I and enabling 
its drivers. 


It is possible for master 
A to retain control of the 


bus and prevent 
master 
B from getting 
control. 


Master A activates 
the Bus Override (or Bus Lock) 


signal 
which 
keeps BUSY I active allowing 
con- 
trol 
of the 
bus 
to stay 
with 
master 
A. 
This 


guarantees 
a master 
consecutive 
bus cycles for 


software 
or hardware 
functions 
which 
require 


exclusive, continuous 
access to the bus. 


Note that in systems with only asingle 
master it is 


necessary 
to ground the BPRNI 
pin of the master, 


if slave boards are to be accessed. 
In single board 


systems 
which use a CPU board capable 
of Bus 


Vectored Interrupt 
operation, the BPRNI 
pin must 


also be grounded. 


In a single master 
system bus transfer 
efficiency 


may be gained 
if the BUS OVERRIDE 
signal 
is 


kept active continuously. 
This permits the master 


to maintain 
control of the bus at all times, there- 


fore sa ving the overhead of the master reacquiring 
the bus each time it is needed. 


The 
CBRQI 
line may 
be used by a master 
in 
control of the bus to determine 
if another 
master 
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requires the bus. If a master currently in control of 
the 
bus 
sees the CBRQI 
line 
inactive, 
it will 


maintain 
control of the bus between adjacent 
bus 


accesses. 
Therefore, when a bus access is required, 


the master 
saves the overhead 
of reacquiring 
the 
bus. 
If a current bus master sees the CBRQI line 
active, it will then relinquish 
control 
of the bus 


after the current 
bus access and will contend for 


the bus with the other master(s) requiring the bus. 
The relative 
priorities 
of the masters 
will deter- 
mine which master 
receives the bus. 


Note that except for the BUS OVERRIDE state, no 
single master 
may keep exclusive 
control of the 


bus. 
This is true because it is impossible 
for the 


CPU on a master 
to require ccntinuous 
access to 


the bus. Other lower priority masters 
will always 


be able to gain access to the bus between accesses 
of a higher priority master. 


Power 
Fail Considerations 
- The MULTIBUS 


P2 connector signals provide a means of handling 
power failures. 
The circuits 
required 
for power 


~I 


4.75 VDC 
MIN 
" 


failure 
detection 
and handling 
are optional 
and 


must be supplied 
by the user. 
Figure 
11 shows 
the timing of a power fail sequence. 


The power supply 
monitors 
the AC power level. 


".'hen power drops below an acceptable 
value, the 
power supply raises ACLO which tells the power 
fail logic that a minimum of three milliseconds will 
elapse before DC power will fall below regulated 
voltage levels. 
The power fail logic sets a sense 
latch (PFSN/) 
and generates an interrupt 
(PFIN I) 
to the processor 
so the processor 
can 
store its 


environment. 
After a 2.5 millisecond 
timeout, the 
memory protect signal (MPRO/) 
is asserted by the 
power fail logic preventing 
any memory activity. 


As power 
falls, 
the 
memory 
goes on standby 
power. 
Note that 
the power fail logic must be 
powered from the standby 
source. 


As the AC line revives, the logic voltage level is 
monitored 
by the power supply. 
After power has 
been 
at its operating 
level for one millisecond 
minimum, 
the power supply sets the signal ACLO 
low, beginning 
the restart 
sequence. 
First, 
the 
memory protect line (MPRO/) 
then the initialize 
line (INIT I) become inactive. 
The bus master now 
starts 
running. 
The bus master checks the power 
fail latch (PFSN/) 
and, ifitfinds 
it set, branches to 


a power up routine which resets the latch (PFSR/), 
restores the environment, 
and resumes execution. 


Note that INITI is activated 
only after DC power 


has risen to the regulated 
voltage levels and must 


stay low for five milliseconds 
minimum before the 


system is allowed to restart. 
Alternatively, 
INIT I 


may be held low through 
an open collector device 


by MPROI. 


How the power failure equipment 
is configured is 


left to the system 
designer. 
The backup 
power 


source may be batteries 
located 
on the memory 


boards 
or more elaborate 
facilities 
located 
off- 
board. 
The 
location 
of the 
power· fail 
logic 


determines 
which MULTIBUS powerfaillines 
are 


used. Pins on the P2 connector have been specified 
for the power failure functions 
for use as needed. 


To further clarify the location and use ofthe power 
fail circuitry, 
an example of a typical 
power fail 


system block diagram 
is shown in Figure 
12. A 


single board computer and a slave memory board 
are contained 
in the system. 
It is desired to power 


the memory circuit elements of the memory board 
from auxiliary 
power. The single board computer 


will remain 
on the main 
power supply. 
To ac- 
complish 
this, user supplied power fail logic and 


an auxiliary 
power supply have been included in 


the system. 


The single board computer is powered from the PI 
power 
lines 
and 
accesses 
the 
P2 signal 
lines 


PFIN/, 
PFSNI 
and PFSRI 
(only the P2 signal 


lines 
used by a particular 
functional 
block are 


shown on the block diagram). 
The PFSRI 
line is 


driven from two sources: a front panel switch and 
the single board computer. 
The front panel switch 


is used during normal power-up to reset the power 
fail sense latch. 
The single board computer uses 
the PFSRI 
line to reset the latch during a power-up 


sequence 
after 
a power failure. 
Current 
single 


board 
computers 
must 
access 
the 
PFSNI 
and 


PFSRI 
signals 
either 
directly 
with 
dedicated 


circuitry 
and a P2 pin connection 
or through 
the 


parallel I/O lines with a cable connection from the 
parallel 
I/O connector 
to the P2 connector. 


The slave memory board uses both the PI and P2 
power lines, the P2 power lines are used (at all 
times) to power the memory circuit elements 
and 


other support circuits, the PI power lines power all 
other circuitry. 
In addition, 
the MPROI 
line is 


input and used to sense when memory contents 
should be protected. 


The power fail logic contains 
the power fail sense 


latch, 
and uses the PFSRI 
and ACLO lines for 


inputs and the PFINI 
PFSN/, 
and MPROI 
lines 


for outputs. 
The power fail logic must be powered 


by the P2 power lines. 


DC Requirements 
- 
The drive and load charac- 


teristics of the bus signals 
are listed in Appendix 
C. The physical locations of the drivers and loads, 
as well as the terminating 
resistor value for each 


bus line, are also specified. Appendix 
D contains 


the MULTIBUS power specifications. 


MUL TIBUS™ Slave 
Interface 


Circuit 
Elements 


There 
are three 
basic 
elements 
of a slave 
bus 


interface: 
address 
decoders, 
bus 
drivers, 
and 


control signal logic. This section discusses each of 
these elements in general terms. A description 
of a 


detailed 
implementation 
of a slave 
interface 
is 


presented in a later section ofthis application 
note. 


Address 
Decoding 
- 
This 
logic decodes 
the 
appropriate 
MULTIBUS 
address 
bits into RAM 
requests, ROM requests, or I/O selects. Care must 
be taken in the design of the address decode logic 
to ensure flexibility in the selection of base address 
assignments. 
Without this flexibility, restrictions 


may 
be placed 
upon various 
system 
configura- 


tions. 
Ideally, switches 
and jumper 
connections 
should 
be associated 
with 
the 
decode logic to 


permit field modification 
of base address 
assign- 


ments. 


The initial 
step in designing 
the address 
decode 


portion of a MULTIBUS 
interface is to determine 


the required number of unique address 
locations. 


This 
decision 
is influenced 
by the 
fact 
that 


address 
decoding 
is usually 
done in two stages. 


The 
first 
stage 
decodes 
the base 
address, 
pro- 


ducing 
an 
enable 
for the 
second 
stage 
which 


generates 
the actual 
device selects 
for the user 


logic. 
A convenient 
implementation 
of this two 


stage decoding scheme utilizes a pair of decoders 
driven by the high order bits of the address for the 
first stage and a second decoder for the low order 
bits of the address bus. This technique 
forces the 


number of unique address locations to be a power 
of two, based at the address 
decoded by the first 


stage. 
Consider the scheme illustrated 
in Figure 


13. 


As shown in Figure 13,the address bits A4 -ABare 
used to produce switch selected outputs of the first 
stage of decoding. 
The 1 out of 8 binary decoders 


have been used. The top decoder decodes address 
lines A4 - A 7, and 
the bottom 
decoder decodes 


address lines A8 -AB. If only address lines AO-A 7 
are being used for device selection, as in the case of 
I/O 
port selection 
in 8-bit systems, 
the bottom 


decoder may be disabled by setting switch S2 to the 
ground position. 
Address lines A7 and AB drive 


enable 
inputs 
E2 or ES of the decoders. 
The 


address 
lines 
AO - AS enter 
the 
second 
stage 


address 
decoder to produce 8 user device selects. 


The second stage decoder must first be enabled by 
an address that corresponds 
to the switch-5elected 


base address. 


Address 
decoding 
must be completed 
before the 


arrival 
of a command. 
Since the command 
may 


become active within 
50 ns after stable 
address, 


the decode logic should 
be kept simple 
with 
a 


minimal 
number of layers of logic. Furthermore, 


the timing is extremely 
critical in systems which 


make use of the inhibit 
lines. 


A linear or unary select scheme in which no binary 
encoding 
of device address 
(e.g., address 
bit AO 


selects device 0, address 
bit Al selects device 1, 


etc.) is performed is not recommended 
because the 


scheme 
offers 
no protection 
in case 
multiple 
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devices are simultaneously 
selected, and because 


the addressing 
within 
such a system is restricted 


by the extent of the address space occupied by such 
a scheme. 


Data 
Bus 
Drivers 
- 
For user designed 
logic 


which simply receives data from the MULTIBUS 
data lines, this portion 
of the bus interface 
logic 


may only consist of buffers. 
Buffers are required 


to ensure that maximum 
allowable bus loading is 


not exceeded by the user logIc. 


In systems 
where the user designed 
logic must 


place data onto the MULTIBUS 
data lines, three- 
state drivers are required. 
These drivers should be 


enabled 
only 
when 
a memory 
read 
command 


(MRDC/) 
or an I/O 
read command 
(IORC/) 
is 


present 
and the module has been addressed. 


When both the read and write functions 
are re- 


quired, parallel bidirectional 
bus drivers (e.g., Intel 


8226,8287, etc.) are used. A note of caution must be 
included 
for the designer 
who uses this type of 
device. 
A problem 
may arise if data 
hold time 


requirements 
must 
be 
satisfied 
for 
user 
logic 


following write operations. 
When bus commands 


are used to directly produce both the chip select for 
the bidirectional 
bus driver and a strobe to a latch 


in the user logic, removal 
of that signal 
may not 


provide the user's latch with adequate 
data hold 


time. Depending 
on the specifics of the user logic, 


this 
problem 
may 
be solved 
by permanently 


enabling 
the data 
buffe~'s receiver 
circuits 
and 


controlling 
only the direction 
of the buffers. 


Control 
Signal 
Logic - The control signal logic 


consists 
of the circuits 
that forward the I/O and 


memory read/write 
commands 
to their respective 


destinations, 
provide 
the 
bus 
with 
a transfer 


acknowledge 
response, 
and 
drive 
the 
system 


interrupt 
lines. 


Bus Command 
Lines 


The 
MULTIBUS 
information 
transfer 
protocol 


lines 
(MRDCI, 
MWTCI, 
IORD/. 
and 
IOWC/) 


should be buffered by devices with very high speed 
switching. 
Because 
the 
bus 
DC requirements 


specify that each board may load these lines with 
2.0 mA, Schottky 
devices are recommended. 
LS 


devices 
are not recommended 
due to their 
poor 


noise immunity. 
The commands 
should be gated 


with a signal indicating 
the base address has been 
decoded to generate read and write strobes for the 
user logic. 


Transfer 
Acknowledge 
Generation 


The user interface 
transfer 
acknowledge 
genera- 
tion 
logic provides 
a transfer 
acknowledge 
re- 
sponse, XACK/, to notify the bus master that write 
data provided by the bus master has been accepted 
or that read data it has requested 
is available 
on 
the MULTIBUS 
data lines. XACK/ allows the bus 
master 
to conclude its current instruction. 


Since XACK/ tim,ing requirements 
depend on both 
the CPU of the bus master 
and characteristics 
of 
the user logic, a circuit is needed which will provide 
a range of easily modified acknowledge responses. 


The transfer 
acknowledge 
signals 
must be driven 
by three-state 
drivers which are enabled when the 
bus 
interface 
is addressed 
and 
a command 
is 
present. 


Interrupt 
Signal Lines 


The asynchronous 
interrupt 
lines must be driven 
by open collector devices with a minimum drive of 
16mA. 


In a typical 
Non Bus Vectored Interrupt 
system, 
logic must be provided 
to assert and latch-up an 
interrupt 
signal. 
In 
addition 
to driving 
the 


MULTI BUS, interrupt 
lines, the latched interrupt 


signal would be read by an I/O operation 
such as 


reading 
the module's status. 
The interrupt 
signal 


would be cleared by writing to the status register. 


III. 
MULTIBUSTM SLAVE 
DESIGN 
EXAMPLE 


A MULTI BUS slave 
design 
example 
has 
been 


included in this application 
note to reinforce the 


theory previously 
discussed. 
The design example 


is of general 
purpose I/O 
slave interface. 
This 
design example could easily be modified to be used 
as 
a slave 
memory 
interface 
by buffering 
the 


address 
signals 
and 
using 
the 
appropriate 
MUL TIBUS memory commands. 
In addition, 
to 
help the reader better understand 
an application 


for an I/O slave interface, two Intel 8255A Parallel 
Peripheral 
Interface 
(PPI) devices are shown con- 
nected to the slave interface. 


The design 
example 
is shown 
in both 8/16-bit 
version and an 8-bit version. The 8/16-bit version 


is an I/O 
interface 
which 
will permit 
a 16-bit 


master 
to perform 8 or 16 bit data transfers. 
8-bit 
masters 
may also use the 8/16-bit version of the 


design example to perform 8-bit data transfers. 


The 8-bit version 
of the design example 
may be 


used by both 8 or 16-bit masters, 
but will only 


perform 8-bit data transfers. 
It does not contain 
the 
circuitry 
required 
to perform 
16-bit 
data 


transfers. 


Both the 8/16-bit version and the 8-bit version of 
the design example were implemented 
on an iSBC 


905 prototype 
board. 
The schematics 
for each of 


the examples 
are given in Appendices 
F and G. 


This 
section 
describes 
the 
organization 
of the 


slave 
interface 
from 
two points 
of view, 
the 


functional 
point 
of view and the programming 
characteristics. 
First, 
the 
principal 
functions 


performed 
by the hardware 
are identified 
and the 


general data flow is illustrated. 
This point of view 


is intended 
as 
an 
introduction 
to the detailed 


description 
provided in the next section; Theory of 


Operation. 
In 
the 
second 
point 
of view, 
the 


information 
needed by a programmer 
to access the 


slave is summarized. 


Functional 
Description 
- 
The function of this 


I/O slave is to provide the bus interface 
logic for 


general 
purpose 
I/O functions 
and for two Intel 


8255A Parallel 
Peripheral 
Interface (PPI) devices. 


Eight device selects (port addresses) 
are available 


for general 
purpose I/O functions. 
One of these 


device select lines is used to read and reset the state 
of an interrupt 
status 
flip-flop, the other 
seven 
device 
selects 
are 
unused 
in this 
design. 
An 


additional 
eight 
110 device port addresses 
are 


used 
by the 
two 8255A devices; 
four 110 port 
addresses 
per 8255A (three I/O port address 
for 


the three parallel 
ports A, B, and C and the fourth 
I/O port address 
for the device control register). 


Figure 14 contains 
a functional 
block diagram 
of 


the slave 
design 
example. 
This 
block diagram 


shows the fundamental 
circuit elements 
of a bus 


slave: 
bidirectional 
data 
bus drivers/receivers, 


address decoding logic and bus control logic. Also 
shown 
is the address 
decoding 
logic for the low 


order four bits, the interrupt 
logic which is selected 


by this decoding logic, and the two 8255A devices. 
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Figure 14. MULTIBUS'· Slave Design Example 
Functional Block Diagram 


Programming 
Characteristics 
- 
The 
slave 
design 
example 
provides 
16 110 port addresses 
which may be accessed 
by user software. 
The 
base address 
of the 16 contiguous 
port addresses 
is selected by wire wrap connections 
on the proto- 
type board. 
The wire wrap connections 
specify 
address 
bits ADR4/ 
- ADRB/. 
They allow the 
selection 
of a base 
address 
on any 
16 byte 
boundary. 
Twelve address bits (ADRO/ -ADRB/) 
are used since 16-bit (8086 based) masters 
use 12 
bits to specity 110 port addresses. 
If an 8 bit (8080 
or 8085 based) master is used with this slave board, 
the high order address bits (ADRB/ -ADRB/) must 
not be used by the decoding circuits; a wire wrap 
jumper position 
(ground position) is provided for 
this. 


The 16 110 port addresses 
are divided into two 
groups of8 port addresses by decoding address line 
ADR3/. 
Port addresses 
XXO - XX7 are used for 
general 
110 functions 
(XX indicates 
any 
hexi- 
decimal digit combination). 
Port address XXOis 
used for accessing the interrupt status flip-flop and 


port addresses 
XXI - XX7 are not used in this 


example. 
Port addresses 
XX8 - XXF are used for 


accessing 
the PPIs. 
If port addresses 
XX8 - XXF 


are selected, then ADRO/ is used to specify which 
of two PPIs 
are selected. 
If the address 
is even 


(XX8, XXA, XXC, or XXE) then one PPI is selected. 
If the address 
is odd (XX9, XXB, XXD, or XXF), 


then the other PPI is selected. ADR1/ and ADR2/ 
are 
connected 
directly 
to the 
PPIs. 
Table 
1 


summarizes 
the I/O 
port addresses 
of the slave 


design 
example. 
Note that 
if a 16-bit master 
is 


used, it is possible to access the slave in a byte or 
word mode. 
If word access 
is used with 
port 


address 
XX8, XXA, XXC, or XXE, then 
16 bit 


transfers 
will occur between 
the PPIs 
and 
the 


master. 
These 16 bit transfers 
occur because an 


even address has been specified and the MULTI- 
BUS 
BHEN / 
signal 
indicates 
that 
a 16-bit 


transfer 
is requested. 


Theory 
of Operation 


In the pre"ceding section, each of the slave design 
example 
functional 
blocks 
was 
identified 
and 
briefly explained. 
This section explains how these 


functions 
are implemented. 
For detailed 
circuit 
information, 
refer to the schematics 
in Appendices 


F and G. The schematic 
in Appendix 
F is on a 


foldout page so that the following text may easily 
be related to the schematic. 


The discussion ofthe theory of operation is divided 
into 
five segments, 
each 
of which 
discusses 
a 


different 
function 
performed 
by the MULTIBUS 


slave design example. 
The five segments 
are: 


1. Bus address 
decoding 


2. Data buffers 


3. Control signals 


4. Interrupt 
logic 


5. PPI operation 


Each of these topics are discussed 
with regard to 


the 
8/16-bit 
version 
of the 
design 
example; 


followed by a discussion 
of the circuit elements 


which 
are required 
by the 8-bit version 
of the 


interface. 


Bus Address 
Decoding 
- 
Bus address decoding 


is performed by two 82051 out of8 binary decoders. 
One decoder (A3) decodes address 
bits ADR8/ 
- 
ADRB/ 
and 
the 
second 
decoder 
(A2) decodes 


address 
bits ADR4/ - ADR7/. 
The base address 


Table 1 


SLAVE DESIGN EXAMPLE PORT ADDRESSES 


I/O PORT ADDRESS 
READ 
WRITE 


BYTE ACCESS 


XXO 
Bit 0 = Interrupt Status 
Reset Interrupt Status 


XX1 - XX? 
Unused 
Unused 


XX8 
Parallel Port A, Even PPI 
Parallel Port A, Even PPI 


XX9 
Parallel Port A, Odd PPI 
Parallel Port A, Odd PPI 


XXA 
Parallel Port B, Even PPI 
Parallel Port B, Even PPI 


XXB 
Parallel Port B, Odd PPI 
Parallel Port B, Odd PPI 


XXC 
Parallel Port C, Even PPI 
Parallel Port C, Even PPI 


XXD 
Parallel Port C, Odd PPI 
Parallel Port C, Odd PPI 


XXE 
Illegal Condition 
Control, Even PPI 


XXF 
Illegal Condition 
Control, Odd PPI 


WORD ACCESS 


XXO 
Bit 0 = Interrupt Status 
Reset Interrupt Status 


XX2 - XX6 
Unused 
Unused 


XX8 
Parallel Port A, Even and Odd PPls 
!Parallel Port A, Even and Odd PPls 


XXA 
Parallel Port B, Even and Odd PPls 
Parallel Port B, Even and Odd PPls 


XXC 
Parallel Port C, Even and Odd PPls 
Parallel Port C, Even and Odd PPls 


XXE 
Illegal Condition 
Control, 
Even and Odd PPls 


XX = Any hex digits, assigned by jumpers; XX defines the base address. 


selected is determined 
by the position of wire wrap 


jumpers. 
The outputs 
of the two decoders 
are 
ANDed together to form the BASE ADR SELECT I 
signal. 
This 
signal 
specifies 
the base 
address 
for a group of 16 I/O ports. 
Using the wire wrap 


jumper positions 
shown in the schematic, 
a base 
address 
of E3 has been selected. 
Therefore, 
this 
MULTIBUS 
slave board will respond to I/O port 


addresses 
in the E30 - E3F range. 


If this slave board is to be used with 8-bit MULTI- 
BUS masters, the high order address bits must not 
be decoded. 
Therefore, 
the 
wire wrap 
jumper 
which 
selects the output of decoder A3 must be 
placed in the top (ground) position (pin 10 of gate 
A9 to ground). 


The low order 4 address lines (ADROI -ADR3/) are 
buffered 
and 
inverted 
using 
74LS04 inverters. 
These 
address 
lines 
are 
input 
to an 8205 for 


decoding 
a chip select for the interrupt 
logic; the 
address 
lines are also used directly by the PPls. 
LS-Series logic is required for buffering to meet the 
MULTIBUS 
specification 
for IlL (low level input 


current). 
S-Series or standard 
series logic will not 


meet this specification. 


Address 
decoder A4 is used to decode addresses 


E30 - E37. The CSOI output of this decoder is used 
to select the interrupt 
logic, thus I/O port address 


E30 is used to read and reset the interrupt 
latch. 


The remaining 
outputs 
from decoder A4 (CSll 
- 
CS7I) are not used in this example. 
They would 


normally 
be used to select other 
functions 
in a 


slave board with more capability. 
Note that in the 


schematic 
shown 
in Appendix 
G for the 
8-bit 


version 
of this 
slave 
design 
example, 
the high 
order (ADR81 - ADRB/) 
address 
decoder is not 


included and the BHEN I signal is not used. 


Data 
Buffers 
- 
Intel 
8287 8-bit 
parallel 
bi- 


directional 
bus drivers 
are used for the MULTI- 
BUS data lines DATOI - DATF/. 
In the 8/16-bit 
version 
of the 
slave 
board, 
three 
8287 drivers 
are used. 


When an 8-bit data 
transfer 
is requested, 
either 


driver A5, which 
is connected 
to on-board 
data 


on-board 
data 
Imes 
UI:S - Ul', 
IS used. 
11 a oyte 


transfer 
is requested 
from an even address, driver 


A5 will be selected. 
If a byte transfer 
from im odd 


address is requested, driver A6 will be selected. All 
byte 
transfers 
take 
place 
on MULTIBUS 
data 


lines 
DATOI 
- DAT7I. 
When 
a word 
(16-bit) 


transfer 
is requested from an even address, drivers 


A5 and A7 will be used. Note that if a user program 
requests 
a word transfer 
from an odd address, 


16-bit 
masters 
in 
the 
iSBC 
product 
line 
will 


actually 
perform two byte transfer 
requests. 


The 
logic which 
determines 
the 
chip selection 


(8287 input signal OE, output enable) signals 
for 


the bus drivers 
uses the low order 
address 
bit 


(ADRO/) 
and 
the 
buffered 
Byte 
High 
Enable 


signal 
(BHENBLI). 
Note that 
the MULTIBUS 


signal 
BHENI 
has been buffered with an 74LS04 


inverter. 
This is done to meet the bus address line 


loading 
specification. 
The SWAP BYTEI 
signal 


which is generated 
is qualified by the BD ENBLI 
signal 
and used to select the bus drivers. 


The steering 
pin for the 8287 drivers is labelled T 


(transmit) 
and is driven by the signal RD. When 


an input (read) request is active or when neither a 
read 
or write 
command 
is being 
serviced, 
the 


direction of data transfer 
ofthe 8287 will be set for 


B to A. 


The 8287 drivers are set to point IN (direction B to 
A) when no MULTIBUS 
I/O transfer 
command is 


being serviced for two reasons. 
First, if the driver 


were pointed 
OUT (direction A to B) and a write 


command 
occured, it would be necessary 
to turn 


the 
buffers 
IN and 
set the OE (output 
enable) 


signal 
active before the data could be transferred 


to the on-board 
bus. 
A possibility 
of a "buffer- 


fight" could occur in some designs ifthe OE signal 
permitted 
an 8287 to drive the MULTIBUS 
data 


lines momentarily 
before the steering signal could 


switch the direction of the 8287. In this case, both 
the MULTIBUS 
master 
and the slave would be 


driving 
the data lines; this is not recommended. 
(In this particular 
design, the steering signal will 


always 
stabilize 
before the OE signal 
becomes 


active.) 


The second reason the driver is pointing 
IN when 


no command 
is present 
is due to the "data 
valid 


after WRITE" 
requirements 
of the 8255As. 
The 


8255A requires that data remain on its data lines 
for 30 ns after the WRITE command 
(WR at the 


8255A) is removed. 
This requirement 
will be met if 


the direction 
of the 8287 drivers is not switched 


(w rtTI 
could have 
been usen to steer tne 
1:S<:1l ( 


instead 
of RD); and if the capacitance 
of the on- 


board data bus lines is sufficient to hold the data 
values on the bus after the 8287 OE signal and the 
8255A PPI WRT1signal go inactive. 
The on-board 


data 
bus may easily 
be designed 
such that 
the 


capacitance 
of the lines is sufficient to meet the 30 


ns data hold time requirement. 
In addition, 
the 


current leakage of all devices connected to the on- 
board bus must be kept small to meet the 30 ns data 
hold time requirement. 


The 8-bit version of this design example uses only 
one 8287 instead 
of the three required by the 8/16- 


bit version. 
The logic required to control the swap 


byte buffer is also not necessary. 
The chip select 


signal used for the 8287 is the BD ENBLI 
signal. 


Control 
Signals 
- 
The 
MULTIBUS 
control 


signals 
used by this 
slave 
design 
example 
are 


IORCI, 
IOWCI, 
and XACKI. 
IORCI 
and IOWCI 


are qualified by the BASE ADR SELECT 1signal 
to form the signals 
RD and WRT. RD and WRT 


are used to drive the interrupt 
logic, the PPI logic 


and the XACKI 
(transfer 
acknowledge) 
logic. 


For the XACKI 
logic RD and WRT are ORed to 


form the BD ENBLI 
signal which is inverted and 


used to drive the CLEAR pin of a shift register. 
When the slave board is not being accessed, 
the 


CLEAR pin of the shift register 
will be low (BD 


ENBLI 
is high). 
This causes the shift register to 


remain cleared and all outputs of the shift register 
will be low. When the slave board is accessed, the 
CLEAR pin will be high, and the A and B inputs 
(which are high) will be clocked to the output pins 
by CCLKI. 
To select a delay for the XACKI 
signal, 


a jumper must be installed 
from one of the shift 


register 
output 
pins to the 8089 tri-state 
driver. 


Each 
of the shift register 
output 
pins select an 


integer multiple 
of CCLKI 
periods for the signal 


delay. 
Since the CCLKI 
signal is asynchronous, 


the actual 
delay 
selected 
may only be specified 


with a tolerance 
of one CCLKI 
period. 
In this 
example 
a delay 
of 3 - 4 CCLKI 
periods 
was 


selected; 
with 
a CCLKI 
period 
of 100 ns, 
the 


XACKI 
delay would occur somewhere 
within the 


range 
of 300 - 400 ns from the time when 
the 


CLEAR signal goes high. 


The control signal logic used in the 8-bit version of 
the slave design example is identical 
to the logic 


used in the 8/16-bit version. 


Interrupt 
Logic 
- 
The interrupt 
logic uses a 


74S74 flip-flop to latch an asynchronous 
interrupt 


request 
from some exterp.al logic. 
The Q output 


of the INTERRUPT 
REQUEST 
LATCH IS output 


through 
an 
open 
collector 
gate 
to one of the 


MULTIBUS 
interrupt 
lines. 
The 
state 
of the 


INTERRUPT 
REQUEST 
LATCH is transferred 
to the INTERRUPT 
STATUS 
LATCH 
when a 


read command 
is performed 
on 110 port BASE 


ADDRESS+O (E30 for the jumper 
configuration 


shown). 
The Q output of INTERRUPT 
STATUS 


LATCH is used to drive data 
line Do of the on- 


board data bus by using an 8089 tri-state driver. 
If a user program 
performs 
an INPUT from 110 


port E30, data bit 0 will be set to I if the INTER- 
RUPT REQUEST 
LATCH is set. 


The purpose of INTERRUPT 
STATUS LATCH is 


to minimize 
the possibility 
of the asynchronous 


interrupt 
occuring 
while the interrupt 
status 
is 


being read by a bus master. 
If the latch was not 


included in the design imd an asynchronous 
inter- 


rupt 
did occur while 
a bus master 
is, reading 
MULTIBUS data line DATOI, a data buffer on the 
master 
could go into 
a meta-stable 
state. 
By 


adding 
the extra 
latch, which is clocked by the 


10RDI command for 110' port E30, the possibility 
of data line DATOI 
changing 
during a bus master 


read operation 
is eliminated. 


The INTERRUPT 
REQUEST 
LATCH is cleared 


when a user program performs an OUTPUT to 110 
port E30. 


This 
interrupt 
structure 
assumes 
that 
several 


interrupt 
sources may exist on the same MULTI- 


BUS interrupt line (for example, INT3/). When the 
MULTI BUS master gets interrupted, 
it must poll 


the possible sources of the interrupt 
received and 


after 
determining 
the source of the interrupt, 
it 


must clear the INTERRUPT 
REQUEST 
LATCH 


for that particular 
interrupt 
source. 


The interrupt 
logic for the 
8-bit version 
of the 


design example is identical to the interrupt logic of 
the 8/16-bit version of the design example. 


PPI Operation 
- 
Two 8255A Parallel Peripheral 
Interface 
(PPI) devices are shown 
interfaced 
to 


the slave design example logic. 
One PPI is con- 


nected to the on-board data bus lines DO- D7 and 
is addressed 
with 
the even 110 port addresses 
E38, E3A, E3C, and 
E3E. 
The second 
PPI is 


connected to data bus lines D8 - DF and is address- 
ed with 
the odd 110 port 
addresses 
E39, E3B, 


E3D, and E3F. The even or odd 110 port selection 
is controlled 
by using the ADRO address 
line in 


the chip select term of the PPls. 
In addition, the 


odd PPI 
(All) 
is selected 
,when the BHENBL 


term is high. 
This occurs when 
the MULTIBUS 


signal 
BHENI 
is low indicating 
that 
a word 


(Iq-bit) 110 instruction 
is being executed. 
When 


a word I/O instr\).ction is executed, both PPls will 
perform the 110 operation 
specified. 


The specifications 
of the 8255A device state that 


the address 
lines AO and Al and the chip select 


lines must be stable before the RD or WR lines are 
activated. 
The MULTIBUS 
specification 
address 


set-up time of 50 ns and the short gate propagation 
delays in this design assure that the address lines 
are stable before RD or WR are active. 


Tpe data 
hold requirements 
of the 8255A were 


discussed 
in a previous section. 
The 8255A speci- 


fication ~tates that data will be stable on the data 
bus lines a maximum 
of 250 ns after 
a READ 


command. 
This specification 
was used to select 


the delay for the XACKI 
signal. 


The PPI 
operation 
for the 8-bit version 
of the 


design example is slightly different than that used 
for the 8/I6-bit 
version. 
The chip select signal for 


the bottom PPI does not use the BHENBL 
term 


since I6-bit data transfers 
are not possible with an 


8-bit 110 slave board. 
Also, the chip select and 


address signals have been swapped so the top PPI 
occupies 
110 address 
range 
X8 - XB, and 
the 


bottom PPI occupies 110 'address range XC -XF (X 
is the base 
address 
of the 8-bit version). 
This 


swapping 
of the address lines was not necessary; 


however, it was thought to be more convenient 
to 


access the PPls in two groups of 4 contiguous 110 
port addresses'. 


This application 
note has shown the structure 
of 


the Intel MULTIBUS 
system bus. 
The structure 


supports a wide range of system modules from the 
Intel OEM Microcomputer 
Systems 
product line 


that 
can be extended 
'with the addition 
of user 


designed 
modules. 
Because 
the user designed 


modules are no doubt unique to particular 
applica- 
tions, a goal of this application 
note has been to 


describe in detail the singular 
common element - 


the 
bus 
interface. 
Material 
has 
also 
been 
presented 
to assist the systems designer to under- 


standing 
the 
bus 
functions 
so that 
successful 
systems integration 
can be achieved. 


APPENDIX 
A 


PIN ASSIGNMENT 
OF BUS SIGNALS ON MUL TIBUS BOARD P1 CONNECTOR 


(COMPONENT 
SIDE) 
(CIRCUIT 
SIDE) 


PIN 
MNEMONIC 
DESCRIPTION 
PIN 
MNEMONIC 
DESCRIPTION 


1 
GND 
Signal GND 
2 
GND 
Signal 
GND 
3 
+5V 
+ 5Vdc 
4 
+5V 
+ 5Vdc 
POWER 
5 
+5V 
+ 5Vdc 
6 
+5V 
+ 5Vdc 
SUPPLIES 
7 
+12V 
+12Vdc 
8 
+12V 
+12Vdc 
9 
-5V 
-5Vdc 
10 
-5V 
-5Vdc 
11 
GND 
Signal GND 
12 
GND 
SignalGND 


13 
BCLKI 
Bus Clock 
14 
INIT/ 
Initialize 
15 
BPRNI 
Bus Pri. In 
16 
BPROI 
Bus Pri. Out 
BUS 
17 
BUSYI 
Bus Busy 
18 
BREQI 
Bus Request 
CONTROLS 
19 
MRDCI 
Mem Read Cmd 
20 
MWTCI 
Mem Write Cmd 
21 
10RCI 
I/O Read Cmd 
22 
10WCI 
1/0 Write Cmd 
23 
XACKI 
XFER Acknowledge 
24 
INH11 
Inhibit 
1 disable 
RAM 


BUS 
25 
Reserved 
26 
INH21 
Inhibit 
2 disable 
PROM or ROM 


CONTROLS 
27 
BHENt 
Byte High Enable 
28 
AD101 


AND 
29 
CBRQ! 
Common 
Bus Request 
30 
AD111 
Address 


ADDRESS 
31 
CCLK! 
Constant 
Clk 
32 
AD121 
Bus 
33 
INTAI 
Intr Acknowledge 
34 
AD13! 


35 
INT61 
Parallel 
36 
INT7! 
Parallel 


INTERRUPTS 
37 
INT41 
Interrupt 
38 
INT51 
Interrupt 
39 
INT21 
Requests 
40 
INTJI 
Requests 
41 
INTOI 
42 
INT1! 


43 
ADRE! 
44 
ADRFI 
45 
ADRCI 
46. 
ADRDI 
47 
ADRAI 
Address 
48 
ADRB/ 
Address 


ADDRESS 
49 
ADR81 
Bus 
50 
ADR91 
Bus 
51 
ADR61 
52 
ADR71 
53 
ADR4! 
54 
ADR5! 
55 
ADR2! 
56 
ADR31 
57 
ADRO! 
58 
ADR11 


59 
DATEI 
60 
DATFI 
61 
DATC! 
62 
DATDI 
63 
DATA! 
Data 
64 
DATB! 
Data 


DATA 
65 
DAT81 
Bus 
66 
OATS I 
Bus 
67 
DAT61 
68 
DAT71 
69 
DAT41 
70 
DAT51 
71 
DAT21 
72 
DAT31 
73 
DATOI 
74 
DAT1! 


75 
GND 
Signal GND 
76 
GND 
Signal GND 
77 
Reserved 
78 
Reserved 
POWER 
79 
-12V 
-12Vdc 
80 
-12V 
-12Vdc 
SUPPLIES 
81 
+5V 
+5Vdc 
82 
+5V 
+5Vdc 
83 
+5V 
+5Vdc 
84 
+5V 
+5Vdc 
85 
GND 
Signal GND 
86 
GND 
SignalGND 


All 
Mnemonics 
© Intel 
Corporation 
1978 


APPENDIX A (Continued) 


P2 CONNECTOR 
PIN ASSIGNMENT 
OF OPTIONAL 
BUS SIGNALS 


(COMPONENT 
SIDE) 
(CIRCUIT 
SIDE) 


PIN 
MNEMONIC 
DESCRIPTION 
PIN 
MNEMONIC 
DESCRIPTION 


1 
GND 
Signal GND 
2 
GND 
Signal GND 


3 
5 VB 
+5V Battery 
4 
5 VB 
+5V Battery 
5 
Reserved 
6 
vCCPP 
+ 5V Pulsed 
Power 
7 
-5 VB 
-5V Battery 
8 
-5 VB 
-5V Battery 
9 
Reserved 
10 
Reserved 


11 
12 VB 
+12V Battery 
12 
12 VB 
+12V Battery 
13 
PFSRI 
Power Fail Sense Reset 
14 
Reserved 


15 
-12 VB 
-12V Battery 
16 
-12 VB 
-12V Battery 
17 
PFSNI 
Power Fail Sense 
18 
ACLO 
AC Low 


19 
PFINI 
Power Fail Interrupt 
20 
MPROI 
Memory 
Protect 


21 
GND 
Signal GND 
22 
GND 
Signal GND 


23 
+15V 
+15V 
24 
+15V 
+15V 


25 
-15V 
-15V 
26 
-15V 
-15V 


27 
PAR11 
Parity 
1 
28 
HALTI 
Bus Master 
HALT 
29 
PAR21 
Parity 
2 
30 
WAITI 
Bus Master WAIT STATE 
31 
32 
ALE 
Bus Master ALE 
33 
34 
Reserved 


35 
36 
Reserved 


37 
38 
AUX RESETI 
Reset switch 
39 
40 


40 
42 


43 
> Reserved 
44 


45 
46 


47 
48 


49 
50 
Reserved 


51 
52 


53 
54 


55 
56 


57 
58 


59 
I 
60 


Notes: 


1. PFIN, on slave modules, 
if possible, 
should 
have the option of connecting 
to INTOI on P1. 
2. All undefined 
pins are reserved 
for future 
use. 


All Mnemonics 
@ Intel Corporation 
1978 


APPENDIX 
B 


BUS TIMING 
SPECIFICATIONS 
SUMMARY 


Plrlmeter 
Description 
Minimum 
Maximum 
Units 


tBCY 
Bus Clock 
Period 
100 
D.C. 
ns 


tBW 
Bus Clock Width 
0.35tBCY 
0.65 tBCY 


(Not Restricted) 


tSKEW 
BCLK/skew 
3 
ns 


tpD 
Standard 
Bus 
3 
Propagation 
Delay 


tAS 
Address 
Set·Up 
Time 
50 
ns 
(at Slave Board) 


tDS 
Write Data Set 
50 
ns 


UpTime 


tAH 
Address 
Hold Time 
50 
ns 


tDHW 
Write Data Hold Time 
50 
ns 


tDXL 
Read Data Set 
a 
ns 


Up Time To XACK 


tDHR 
Read Data Hold Time 
a 
65 
ns 


tXAH 
I 
Acknowledge 
Hold 
a 
65 
ns 


Time 


tXACK 
Acknowledge 
Time 
a 
8 
P.s 


tCMD 
I 
Command 
Pulse 
100 
95 
ns 


Width 


tlD 
Inhibit 
Delay 
a 
100 
ns 


(Recommend 
< 100 ns) 


tXACKA 
Acknowledge 
Time of 
tIAD+50 
ns 
1500 


of an Inhibited 
Slave 


tXACKB 
Acknowledge 
Time of 
1.5 
8 
jJ.s 


an Inhibiting 
Slave 


tlAD 
Acknowledge 
Disable 
a 
100 
ns 


from Inhibit 
(An 
(arbitrary) 
internal 
parameter 
on 
an inhibited 
slave; 


used to determine 
tXACKA 
Min.) 


tAIZ 
Address 
to Inhibits 
•. 
100 
ns 


High 
Delay 


tlNTA 
INTAI 
Width 
250 
ns 


tCSEP 
Command 
Separation 
100 
ns 


APPENDIX 
B (Continued) 


BUS TIMING 
SPECIFICATIONS 
SUMMARY 


Parameter 
Description 
Minimum 
Maximum 
Unils 


IBREQL 
IBCLKI 
to BREQI 
0 
35 
ns 


Low Delay 


tBREQH 
IBCLK/lo 
BREQf 
0 
35 
ns 


High Delay 


IBPRNS 
BPRN f to IBCLKf 
22 
ns 


Setup Time 


tBUSY 
BUSY I delay 
0 
70 
ns 


from IBCLKf 


tBUSYS 
BUSY f to IBCLKf 
25 
ns 


Setup Time 


tBPRO 
IBCLKf 
to BPROf 
0 
40 
ns 
(CLK to Priority 
Out) 


tBPRNO 
BPRNI 
to BPROf 
0 
30 
ns 


(Priority 
In to Out) 


tCBRO 
IBCLK/to 
CBRQI 
0 
60 
ns 
(CLKto 
Common 
Bus Request) 


tCBRQS 
CBRQI 
to IBCLKI 
35 
ns 


Setup Time 


tXCD 
XACKI 
to Command 
I 
0 
1500 
ns 


Delay 


IBSYO 
CBRQ/I 
and BUSY/I 
- 
12 
ps 


to BUSY/I 


tCCY 
C-clock 
Period 
100 
110 
ns 


tcw 
C-clock 
Width 
0.35 tCCY 
0.65 tCCY 
ns 


tlNIT 
INIT/Width 
5 
ms 


tlNITS 
INIT I to MPROI 
100 
ns 


Setup Time 


tpBD 
Power 
Backup 
0 
200 
ns 


Logic 
Delay 


tPFINW 
PFINI Width 
25 
ms 


tMPRO 
MPROI 
Delay 
2.0 
25 
ms 


tACLOW 
ACLOI 
Width 
3.0 
ms 


tPFSRW 
PFSRI Width 
100 
ns 


ITOUT 
Timeout 
Delay 
5 
~(DC) 
ms 


lOCH 
D.C. Power Supply 
3.0 
ms 


Hold from ALCOI 


tDCS 
D.C. Power Supply 
5 
ms 
Setup to ACLOI 


APPENDIX C 


BUS DRIVERS, RECEIVERS, AND TERMINATIONS 


Orlver1,3 
Receiver 
2.3 
Termination 


Bus Slgnlls 
Lacltlan 
Type 
IOL 
IOH 
Co 
Lacltlan 
IlL 
IIH 
CI 
Location 
Type 
R 
Units 


M1nml 
Mln~1 
MlXpl 
Maxma 
MIX~I 
MI'pl 


OATO/-DATFI 
Masters 
TRI 
16 
-2000 
300 
Masters 
-08 
125 
18 
1 place 
Pullup 
22 
KQ 


(16Iines) 
and Slaves 
and Slaves 


ADRO/-ADRB/, 
Masters 
TRI 
16 
-2000 
300 
Slaves 
-0.8 
125 
18 
1 place 
Pullup 
22 
KQ 


BHENI 
(21 lines) 


MRDC/,MWTCI 
Masters 
TRI 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(Memory; 
memory- 
mapped 
110) 


10RCI,IOWCI 
Masters 
TRI 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(110) 


XACKI 
Slaves 
TRI 
32 
-2000 
300 
Masters 
-2 
125 
18 
1 place 
Pullup 
510 
Q 


INH1/,INH21 
Inhibiting 
OC 
16 
- 
300 
Inhibited 
-2 
50 
18 
1 place 
Pullup 
1 
KQ 


Slaves 
Slaves 
(RAM, 
PROM, 


ROM. Memory- 
Mapped 
110) 


BCLKI 
1 place 
TTL 
48 , 
-3000 
300 
Master 
-2 
125 
18 
Mother- 
To + 5V 
220 
Q 


(Master 
us) 
board 
To GND 
330 
Q 


BREQI 
Each 
TTL 
5 
-200 
60 
Central 
2 
50 
18 
Central 
Pullup 
1 
KQ 


Master 
Priority 
Priority 


Module 
Module 
(not 
req) 


BPROI 
Each 
TTL 
5 
-200 
60 
Next 
Master 
-1.6 
50 
18 
(not req) 


Master 
In SerIal 
Priority 
Chain 
at 
Its BPRNI 


BPRNI 
Parallel: 
TTL 
5 
-200 
300 
Master 
-4 
100 
Inot reql 


Central 
PriOrity 
Module 
Senal:Prev 
Masters 
BPROI 


BUSY'. 
eBRQ 
All Masters 
Oe. 
20 
- 
300 
All Masters 
-2 
50 
18 
1 place 
Pullup 
1 
KQ 


INITI 
Master. 
Oe 
32 
- 
300 
All 
-2 
50 
18 
1 place 
Pullup 
22 
KQ 


CCLKI 
1 place 
TTL 
48 
-3000 
300 
Any 
-2 
125 
18 
Mother- 
To + 5V 
220 
Q 


board 
To GND 
330 
Q 


INTAI 
Masters 
TRI 
32 
-2000 
300 
Slaves 
-2 
125 
18 
1 place 
Pullup 
1 
KQ 


(Interrupting 
1101 


INTOI-INTlI 
Slaves 
OC. 
16 
- 
300 
Maslers 
-1.6 
40 
18 
1 place 
Pull up 
1 
KQ 


(8 lines) 


PFSRI 
User's 
Fron 
TTL 
16 
-400 
300 
Slaves, 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


Panel? 
Masters 


PFSNI 
Power 
Back 
TTL 
16 
-400 
300 
Masters 
-1.6 
40 
18 
I place 
Pull up 
1 
KQ 


Up Unit 


ACLO 
Power 
O.e. 
16 
-400 
300 
Slaves. 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


Supply 
Masters 


PFINI 
Power 
Back· 
OC. 
16 
-400 
300 
Masters 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


Up Unit 


MPROI 
Power 
Back- 
TTL 
16 
-400 
300 
Slaves 
-1.6 
40 
18 
1 place 
Pullup 
1 
KQ 


Up Unit 
Masters 


APPENDIX 
C (Continued) 


BUS DRIVERS, RECEIVERS, AND TERMINATIONS 


Driver 1,3 
Receiver 2,3 
Terminaticn 


Bus Signals 
Location 
Type 
IOL 
IOH 
Co 
Location 
IlL 
IIH 
CI 
Location 
Type 
R 
Units 


Minma 
Min~. MUpl 
Maxma 
MaxJlI 
MUpf 


Aux Resell 
User's 
Switch 
- 
- 
- 
Masters 
-2 
50 
18 
None 


Front 
toGND 
Panel? 
(NOle 
51 


Notes: 


1. 
Dnver 
ReqUirements 


10H 
= High Output Current Drive 


tOL 
= Low Output Current Drive 


Co 
= Capacitance Drive Capability 


TRI 
= 3-State Drive 


OC 
= Open Collector Driver 


TTL 
= Totem-pole Driver 


2 
Receiver 
Requirements 


IIH 
= High tnput Current Load 


IlL 
= Low Input Current Load 


C, 
= Caoacitive Load 


3. TTL low state must be 2 -0.5v but,;, 
0.8v at the receivers 
TTL high state must be2 
2.0v but ~ 5.5v at the receivers 


4. For the iSBC 80110 and the iSBC 80/10A 
use only 
a 1K pUll-up 
resistor 
to +5v lor BCLKI 
and CCLKI 
termination. 


5. Recommend 
a 4711resistor 
in series 
with 
switch. 


Standard 
(P1) 
Optional 
(P2) 


Analog 
Power 
Battery 
Power Backup 


Ground 
+5 
+ 12 
-12 
+15 
-15 
+5 
+ 12 
-12 
-5 


Mnemonic 
GND 
+5V 
+ 12V 
-12V 
+ 15V 
-15V 
+ 58 
+128 
-128 
-58 


8us Pins 
P1 + 1,2, 
P1 +3,4, 
P1 + 7,8 
P1 + 79, 
P2+ 23, 
P2+ 25, 
P2+ 3,4, 
P2+ 11, 
P2 + 15, 
P2- 
7,8 


11,12, 
5,6,81, 
80 
24 
26 
5,6 
12 
16 


75,76 
82,83, 


85,86 
84 


Nominal 
Output 
Ref. 
+ 5.0V 
+ 12.0V 
-12.0V 
+ 15.0V 
-15.0V 
+5.0V 
+ 12.0V 
-12.0V 
-5.0V 


Tolerance 
from 


Nominal' 
Ref. 
±5"10 
±5"10 
±5"10 
±3"10 
±3"10 
±5"10 
±5"10 
±5"10 
±5"10 


Ripple 
(Pk-Pk)' 
Ref. 
50 mV 
50 mV 
50 mV 
10 mV 
10 mV 
50 mV 
50 mV 
50 mV 
50 mV 


Transient 
Response 
500 p'S 
500p.s 
500 p'S 
100 P.s 
100 p'S 
500 P.s 
500 P.s 
500 P.s 
500 P.s 
Time' 


Transient 
Deviation' 
± 10% 
±10% 
± 10% 
± 10% 
± 10% 
± 10% 
± 10% 
±10% 
± 10% 


NOTES: 


1. Tolerance 
is worst case, including 
initial 
voltage 
setting 
line and load effects 
of power source, temperature 
drift, and any additional 
steady 
state jnflu~nce5. 


2. 
As measured 
over any bandwidth 
not to exceed 
0 to 500 kHz. 
3. As measured 
from the start of a load change 
to the time an output 
recovers 
within 
::t 0.1% of final voltage. 


4. 
Measured 
as the peak deviation 
from the initial 
voltage. 
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I. INTRODUCTION 


The iSBC 957 Intellec-iSBC 
86/12 Interface and 
Execution Package contains the hardware and soft- 
ware required to interface an iSBC 86/12 
Single 
Board Computer with an Intellec Microcomputer 
Development System. The iSBC 957 package gives 
the 8086 user the capability to develop software on 
an Intellec System and then debug this software on 
an iSBC 86/12 board using a program download 
capability and an interactive system monitor. The 
8086 user has all the capabilities of the Intellec sys- 
tem at his disposal and has the powerful iSBC 
86/12 
system 
monitor 
commands 
to 
use 
for 


debugging 8086 programs. 


The iSBC 86/12 board is an Intel 8086 based proc- 
essor board which, in addition to the processor, 
contains 32K bytes of dual port RAM, sockets for 
up to 16K bytes of ROM/EPROM, 
a serial I/O 


port, 
24 
parallel 
I/O 
lines, 
2 
programmable 


counters, 9 levels of vectored priority interrupts, 
and an interface to the MULTIBUS™ system bus. 
The iSBC 957 package consists of monitor EPROMs 
for the iSBC 86/12 board, Loader software for the 
Intellec system, four (4) cable assemblies, assorted 
line drivers and terminators, 
and signal adapters. 


The iSBC 957 package provides the capability of 
downloading 
and 
uploading 
program 
and 
data 
blocks between an iSBC 86/12 board and an Intellec 
system. 
In 
addition, 
monitor 
commands 
and 
displays may be input and viewed from the Intellec 
system console. The iSBC 957 package, when used 
with the iSBC 86/12 board and an Intellec Micro- 
computer Development System, provides the user 
with the capability to edit, compile or assemble, 
link, 
locate, 
download, 
and 
interactively debug 
programs for the 8086 processor. The iSBC 957 
package and the iSBC 86/12 
board form an ex- 


cellent "execution 
vehicle" 
for users developing 


software 
for 
the 
8086 processor 
regardless 
of 


whether the users are 8086 component 
users or 


iSBC 86/12 board users. Using the iSBC 957 pack- 
age 8086 programs may be debugged at the full 5 
MHz speed of the processor. The recommended 
hardware for the execution vehicle is an iSBC 660 
system chassis with an 8 card slot backplane and 
power supply, an iSBC 032 32K byte RAM memory 
board, the iSBC 957 package, and the iSBC 86/12 
board. 


This application note will describe how the iSBC 
957 package may be used to develop and debug 
8086 programs. 
First a description of the iSBC 
86/12 
board will be presented. Readers familiar 


with the iSBC 86/12 board may want to skip this 
section. Next follows a detailed description of the 
iSBC 957 package and the iSBC 86/12 
system 


monitor 
commands. 
A program 
example of 
a 


matrix multiplication routine will then be presented. 
This example will contain both assembly language 
and PL/M-86 
procedures. The steps required to 


compile, 
assemble, 
link, 
locate 
and 
debug 
the 


program code will be explained in detail. A typical 
debugging session using the iSBC 86/12 
system 


monitor will be presented. 


II. THE iSBeM 
86/12 SINGLE BOARD 


COMPUTER 


The iSBC 86/12 Single Board Computer, which is 
a member of Intel's complete line of iSBC 80/86 
computer products, is a complete computer system 
on a single printed-circuit assembly. The iSBC 86/ 
12 board includes a 16-bit central processing unit 
(CPU), 32K bytes of dynamic RAM, a serial com- 
munications interface, three programmable parallel 
I/O ports, programmable timers, priority interrupt 
control, MULTIBUS control logic, and bus expan- 
sion drivers for interface with other MULTIBUS- 
compatible expansion boards. Also included is dual 
port control logic to allow the iSBC 86/12 board 
to act as a slave RAM device to other MULTIBUS 
masters in the system. Provision is made for user 
installation of up to 16K bytes of read only mem- 
ory. Figure 1 contains a block diagram of the iSBC 
86/12 
board and in Appendix A is a simplified 


logic diagram of the iSBC 86/12 board. 


Central Processing Unit 


The central processor for the iSBC 86/12 board is 
Intel's 8086, a powerful 16-bit H-MOS device. The 
225 sq. mil chip contains 29,000 transistors and has 
a clock rate of 5MHz. The architecture includes 
four (4) 16-bit byte addressable data registers, two 
(2) 16-bit memory base pointer registers and two (2) 
16-bit index registers, all accessed by a total of 24 
operand addressing modes for complex data han- 
dling and very flexible memory addressing. 


Instruction 
Set - The 8086 instruction 
repertoire 


includes variable 
length 
instruction 
format 
(in- 
cluding double operand instructions), 8-bit and 16- 
bit signed and unsigned arithmetic operators 
for 


binary, BCD and unpacked ASCII data, and iter- 
ative word and byte string manipulation functions. 
The instruction 
set of the 8086 is a functional 


superset of the 8080A/8085A 
family and 
with 


available software tools, programs written for the 
8080A/8085A can be easily converted and run on 
the 8086 processor. 


Architectural Features - 
A 6-byte instruction queue 


provides pre-fetching of sequential instructions and 
can reduce the 1.21A sec minimum instruction cycle 
to 400 nsec by having the instruction already in the 
queue. 


The stack oriented 
architecture 
facilitates nested 


sub-routines and co-routines, reentrant 
code and 


powerful interrupt handling. The memory expan- 
sion capabilities offer 
a 
1 megabyte addressing 


range. The dynamic relocation scheme allows ease 
in segmentation of pure procedure and data for 
efficient memory utilization. Four segment registers 
(code, stack, data, extra) contain program loaded 
offset values which are used to map 16-bit addresses 
to 20-bit addresses. Each register maps 64K-bytes at 
a time and activation of a specific register is con- 
trolled explicitly by program control and is also 
selected 
implicitly 
by 
specific 
functions 
and 


instructions. 


Bus Structure 


The iSBC 86/12 
board has an internal bus for 
communicating 
with on-board 
memory and I/O 


options, a system bus (the MULTIBUS) for refer- 
encing additional memory and I/O 
options, and 


the dual-port 
bus which allows access to RAM 


from the on-board, CPU and the MULTIBUS Sys- 
tem Bus. Local (on-board) accesses do not require 
MULTIBUS communication, 
making the system 


bus available for use by other MULTIBUS masters 
(i.e. DMA devices and other single board 
com- 


puters transferring to additional system memory). 
This feature allows true parallel processing in a 
multiprocessor environment. In addition, the MUL- 
TIBUS interface can be used for system expansion 
through the use of other 8- and .16-bit iSBC com- 
puters, memory and I/ 0 expansion boards. 


RAM Capabilities 


The iSBC 86/12 
board 
contains 
32K-bytes of 


dynamic read/write 
memory. Power for the on- 


board RAM and refresh circuitry may be option- 
ally provided 
on 
an auxiliary 
power 
bus, 
and 


memory protect logic is included for RAM battery 
backup requirements. The iSBC 86/12 board con- 
tains a dual port controller which allows access to 
the on-board RAM from the iSBC 86/12's 
CPU 
and from any other MULTIBUS master via the 
system bus. The dual port controller allows 8- and 
16-bit accesses from the MULTIBUS System Bus 
and the on-board CPU transfers data to RAM over 
a 16-bit data path. Priorities have been established 
such that memory refresh is guaranteed by the on- 
board refresh logic and that the on-board CPU has 
priority over MULTIBUS requests for access to 
RAM. The dual-port controller includes independent 
addressing logic for RAM access from the on-board 
CPU and from the MULTIBUS system bus. The 
on-board 
CPU will always access RAM starting 
at location OOOOOH.Address jumpers 
allow on- 
board RAM to be located starting on any 8K-byte 
boundary within a 1 megabyte address range for 
accesses from the MULTIBUS system bus. In con- 
junction with tris feature, the iSBC 86/12 board 
has the ability to protect on-board memory from 
MULTIBUS 
access to 
any 
contiguous 
8K-byte 
segments. 
These 
features 
allow 
multi-processor 
systems to establish local memory for'each proces- 
sor and shared system (MULTIBUS) memory con- 
figurations 
where the total 
system memory size 
(including local on-board 
memory) can exceed 1 
megabyte without addressing conflicts. 


EPROM/ROM 
Capabilities 


Four sockets are provided for up to 16K-bytes of 
non-volatile read only memory on the iSBC 86/12 
board. 
Configuration 
jumpers 
allow read 
only 
memory to be installed in 2K, 4K, or 8K increments. 


On-board ROM is accessed via 16 bit data paths. 
System memory 
size is easily expanded 
by the 
addition of MULTIBUS compatible memory boards 
available in the iSBC 80/86 family. 


Parallel II 0 Interface 


The iSBC 86/12 board contains 24 programmable 
parallel 
I/ 0 lines implemented 
using the 
Intel 
8255A Programmable 
Peripheral 
Interface. 
The 
system software is used to configure the I/O 
lines 
in any combination of unidirectional input / output 
and bidirectional ports. 


Therefore, the I/O 
interface may be customized to 
meet specific peripheral requirements. In order to 
take full advantage of the large number of possible 
I/O 
configurations, sockets are provided for inter- 
changeable 
I/O 
line 
drivers 
and 
terminators. 
Hence, the flexibility of the I/O interface is further 


enhanced by the capability of selecting the appro- 
priate combination 
of optional 
line drivers and 
terminators 
to provide the required sink current, 


polarity, and drive/termination 
characteristics for 
each application. The 24 programmable I/O 
lines 


and signal ground lines are brought out to a 50-pin 
edge connector that mates with flat, woven, or 
round cable. 


SerialI/O 


A programmable 
communications 
interface using 
the 
Intel 
825lA 
Universal 
Synchronous/ Asyn- 


chronous Receiver/Transmitter 
(USART) is con- 
tained 
on the iSBC 86/12 
board. 
A software 


selectable baud rate generator provides the USART 
with all common communication frequencies. The 
USART can be programmed 
by the system soft- 


ware to select the desired asynchronous 
or syn- 


chronous 
serial data 
transmission 
technique 
(in- 
cluding IBM Bi-Sync). The mode of operation (i.e., 
synchronous or asynchronous), data format, con- 
trol character format, parity, and baud rate are all 
under program control. The 8251A provides full 
duplex, double buffered transmit and receive capa- 
bility. Parity, overrun, and framing error detection 
are all incorporated in the USART. The RS232C 
compatible interface on each board, in conjunction 
with the USART, provides a direct interface to 
RS232C compatible terminals, cassettes, and asyn- 
chronous and synchronous modems. The RS232C 
command lines, serial data lines, and signal ground 
line are brought out to a 26 pin edge connector that 
mates with RS232C compatible flat or round cable. 
The iSBC 530 teletypewriter adapter provides an 
optically isolated interface for those systems reo 
quiring a 20 mA current 
loop. 
The iSBC 530 


adapter may be used to interface the iSBC 86/12 
board to teletypewriters or other 20 mA current 
loop equipment. 


Programmable Timers 


The iSBC 86/12 board provides three independent, 
fully programmable 
16-bit interval timers / event 


counters utilizing the Intel 8253 Programmable In- 
terval Timer. Each counter is capable of operating 
in either BCD or binary modes. Two of these 
timers / counters are available to the systems de- 
signer to generate accurate time intervals under 
software control. Routing for the outputs and gate/ 
trigger inputs of two of these counters is jumper 
selectable. 
The 
outputs 
may 
be 
independently 


routed to the 8259A Programmable Interrupt Con- 
troller and to the I/O 
line drivers associated with 


the 8255A Programmable 
Peripheral Interface, or 


may be routed as inputs to the 8255A chip. The 
gate/trigger 
inputs may be routed to I/O 
termin- 


ators associated with the 8255A or as output con- 
nections from the 8255A. The third interval timer 
in the 8253 provides the programmable baud rate 
generator 
for the iSBC 86/12 
RS232C USART 


serial port. In utilizing the iSBC 86/12, the systems 
designer simply configures, via software, each timer 
independently to meet system requirements. When- 
ever a given time delay or count is needed, soft- 
ware commands to the programmable timers / event 
counters select the desired function. 


The contents of each counter may be read at any 
time during 
system operation 
with simple read 


operations 
for event counting 
applications, 
and 


special commands are included so that the contents 
can be ready "on the fly". 


MULTIBUS™ and Multimaster Capabilities 


The MULTIBUS system bus features asynchronous 
data transfers for the accommodation 
of devices 


with various transfer rates while maintaining maxi- 
mum throughput. Twenty address lines and sixteen 
separate data lines eliminate the need for address / 
data 
multiplexing / demultiplexing 
logic 
used 
in 


other systems, and allow for data transfer rates up 
to 5 megawords / sec. A failsafe timer is included in 
the iSBC 86/12 board which can be used to gener- 
ate an interrupt if an addressed device does not 
respond within 6 msec. 


Multimaster Capabilities - The iSBC 86/12 board 
is a full computer on a single board with resources 
capable of supporting a great variety of OEM sys- 
tem requirements. For those applications requiring 
additional processing capacity and the benefits of 
multiprocessing (Le., several CPUs and / or con- 
trollers 
logically 
sharing 
system 
tasks 
through 


communication over the system bus), the iSBC 86/ 
12 board 
provides 
full MULTIBUS 
arbitration 


control logic. This control logic allows up to three 
iSBC 86/12 boards or other bus masters, including 
iSBC 80 family MULTIBUS compatible 8-bit single 
board computers, to share the system bus in serial 
(daisy chain) priority fashion, and up to 16 masters 
to share the MULTIBUS with the addition of an 
external priority network. The MULTIBUS arbitra- 
tion logic operates synchronously with a MULTI- 
BUS clock (provided by the iSBC 86/12 board or 
optionally provided directly from the MULTIBUS 
System Bus) while data is transferred via a hand- 
shake between the master and slave modules. This 


allows different speed controllers to share resources 
on the same bus, and transfers via the bus proceed 
asynchronously. Thus, transfer speed is dependent 
on transmitting 
and receiving devices only. This 


design prevents slow master modules from being 
handicapped in their attempts to gain control of the 
bus, but does not restrict the speed at which faster 
modules can transfer data via the same bus. The 
most 
obvious 
applications 
for 
the 
master-slave 


capabilities of the bus are multiprocessor configur- 
ations, high speed direct memory access (DMA) 
operations, and high speed peripheral control, but 
are by no means limited to these three. 
Interrupt Capability 


The iSBC 86/ 12 board provides 9 vectored interrupt 
levels. The highest level is the NMI (Non-Maskable 
Interrupt) line which is directly tied to the 8086 
CPU. This interrupt cannot be inhibited by soft- 
ware and is typically used for signalling catastrophic 
events (e.g., power failure). 


The Intel 8259A Programmable 
Interrupt 
Con- 
troller (PIC) provides vectoring for the next eight 
interrupt levels. 


The PIC accepts interrupt requests from the pro- 
grammable parallel and serial I/O 
interfaces, the 
programmable timers, the system bus, or directly 
from peripheral equipment. The PIC then deter- 
mines which of the incoming requests is of the 
highest priority, determines whether this request is 
of higher priority than the level currently being 
serviced, and, if appropriate, issues an interrupt to 
the CPU. Any combination of interrupt levels may 
be masked, via software, by storing a single byte 
in the interrupt mask register of the PIC. The PIC 
generates a unique memory address for each in- 
terrupt 
level. 
These 
addresses 
contain 
unique 


instruction pointers and code segment offset values 
(for expanded memory operation) for each interrupt 
level. In 
systems requiring 
additional 
interrupt 


levels, slave 8259A PIC's may be interfaced via the 
MULTIBUS system bus, 
to generate additional 
vector addresses, yielding a total 
of 65 unique 
interrupt levels. 


Interrupt 
Request Generation - 
Interrupt requests 


may originate from 16 sources. Two jumper select- 
able interrupt requests can be automatically gener- 
ated by the programmable peripheral interface. 


Two jumper 
selectable interrupt 
requests can be 
automatically 
generated by the USART when a 
character is ready to be transferred to the CPU or a 
character is ready to be transmitted. 


A jumper selectable request can also be generated 
by each of the programmable timers. Eight addi- 
tional interrupt request lines are available to the 
user for direct interface to user designated peripher- 
al devices via the system bus, and two interrupt 
request lines may be jumper routed directly from 
peripherals via the parallel I/O 
driver/terminator 


section. 


Power-Fail Control 
Control logic is also included to accept a power-fail 
interrupt 
in conjunction 
with the AC-low signal 
from the iSBC 635 Power Supply or equivalent. 


Expansion Capabilities 


Memory and 1/ 0 capacity may be expanded and 
additional functions added using Intel MULTIBUS 
compatible expansion boards. High speed integer 
and floating point arithmetic capabilities may be 
added by using the iSBC 310 high speed mathe- 
matics unit. Memory may be expanded to I mega- 
byte by adding 
user specified combinations 
of 
RAM boards, 
EPROM 
boards, 
or combination 
boards. Input/output 
capacity may be increased by 


adding 
digital 
1/ 0 and 
analog 
1/ 0 expansion 
boards. Mass storage capability may be achieved 
by adding single or double density diskette con- 
trollers. Modular expandable backplanes and card- 
cages are available to support multiboard systems. 


III. THE iSBCTM957 PACKAGE 


The iSBC 957 Intellec-iSBC 
86/12 Interface and 
Execution Package extends the software develop- 
ment capabilities of the 
Intellec Microcomputer 
Development systems to the Intel 8086 CPU. Pro- 
grams for the 8086 may be written in PL/M-86 
and/or 
assembly language and compiled or as- 


sembled on the Intellec system. These programs 
may then be downloaded from an Intellec ISIS-II 
disk file to the iSBC 86/12 board for execution and 
debug. The programs will execute at the full 5 MHz 
clock rate of the 8086 CPU with no speed degrada- 
tion caused by the iSBC 957 hardware or software. 
Special communication software allows transparent 
access to the powerful interactive debug commands 
in the iSBC 86/12 monitor from the Intellec con- 
sole terminal. 
These 
debug 
commands 
include 


single-step instruction 
execution, 
execution 
with 
breakpoints, memory and register displays, memory 
searches, comparison of two memory blocks and 
several other commands. After a debugging session, 
the debugged program code may be uploaded from 
the iSBC 86/12 
board to an Intellec ISIS-II disk 
file. 


The iSBC 957 Intellec-iSBC 
86/12 Interface and 
Execution Package consists of the following: 


a. Four Intel 2716 EPROMs which contain the sys- 
tem monitor program for the iSBC 86/12 board. 


b. An ISIS-II diskette containing loader software 
for execution in the Intellec which provides for 
communications between the user or an Intellec 
ISIS-II file and the iSBC 86/12 board. Also in- 
cluded on the diskette are a library of routines 
for system console I/O. 


c. Four cable assemblies used for transmitting com- 
mands, code and data between the iSBC 86/12 
board and the Intellec system. 


d. An iSBC 530 adapter assembly which converts 


serial communications signals from current loop 
to RS232C. 


e. Line drivers and terminators used for the iSBC 


86/12 parallel ports. 


f. A small printed circuit board which is plugged 


into an iSBC 86/12 receiver/terminator 
socket 
and is used when program code is downloaded 
or uploaded using the parallel cable. 


iSBCTM-Intellec ™ 
Configurations 


There are two distinct functional configurations for 
the iSBC 957 package; one configuration 
for the 


Intellec Series II, Models 220 or 230 development 
systems and another 
for the Intellec 800 series 


development systems. 


Intellec Series II System Configurations 


When used with Intellec Series II Model 220 or 
230 systems, a set of cables are used to connect the 
serial I/O 
port edge connector on the iSBC 86/12 


board and the SERIAL 1 output port on the Intellec 
system. This configuration 
is shown in Figure 2. 


How this system functions is explained in the fol- 
lowing paragraphs. 


The SERIAL 1 port on the Intellec Series II Model 
220 or 230 system is an RS232 port which is de- 
signed for use with a data terminal. This port may 
be used on the Intellec system for interfacing to 
RS232 devices such as CRT terminals or printers. 
The serial ports on the iSBC 86/12 board and the 
Intellec systems are connected as shown in the 
Figure 2. The flat ribbon cable connected to the 
iSBC 86/12 board has an edge connector for con- 
necting to the board on one end and a standard 
RS232 connector on the other end. The second 
cable, the RS232 Up/Down 
Load cable, has an 


RS232 connector on each end. This cable, however, 


is not a standard cable with the RS232 signals bussed 
between identically numbered pins on each of the 
connectors. The schematic for the cable is shown in 
Figure 3. Note that the TXD (transmit data) and 
the RXD (receive data) and the RTS (ready to send) 
and the CTS (clear to send) signals have been 
crossed. This is done because both the Intellec system 
and the iSBC 86/12 board are configured to act as 
data 
sets which 
are 
communicating 
with 
data 


terminals. Swapping these signals permits the units 
to communicate directly with no modifications to 
the Intellec or iSBC 86/12 systems themselves. 
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Figure 
3. IntellecTM-iSBCTM 
86/12 
RS232 
UP/DOWN 
LOAD Cable 


The software in the Intellec system accepts characters 
output 
from the iSBC 86/12 
board through the 


Intellec SERIAL 1 port. The software then outputs 
these characters on the CRT monitor built into the 
Intellec Series II Model 220 or 230. In a similar 
fashion, 
characters 
input 
from the Intellec key- 


board are passed down the serial link to the iSBC 
86/12 
monitor 
program. 
The 
integrated 
CRT 


monitor and keyboard on the Intellec system then 
becomes the "virtual terminal" of the iSBC 86/12 
monitor program. If this were the only function of 
the iSBC 957 package, there would be no real 
benefit to the user. However, when the "virtual 
terminal" 
capability is combined with the capa- 


bility to download and upload program code and 
data files between the Intellec ISIS-II me system 
and the iSBC 86/12 board, a very powerful soft- 
ware development tool is realized. The software in 
the Intellec system must examine the commands 
which are input from the keyboard and in the case 
of the LOAD and TRANSFER 
commands 
(see 


later sections for details on monitor commands), 
the software must open and read or write ISIS-II 
disk files. 


Transfer rates using Intellec Series II Model 220 or 
230 system are 9600 baud when transferring hexa- 
decimal object files to or from a disk file and 600 
baud 
when transferring 
commands 
between the 


iSBC 86/12 board and the CRT monitor and key- 
board. 
With a 9600 baud transfer rate, it is pos- 
sible to load 64K bytes of memory in about four 
minutes. 


Intellec 800 System Configurations 


The iSBC 957 package may be used with the In- 
tellec 800 system in four different configurations. 
These four configurations are determined by two 


variables. The first variable is whether the iSBC 
86/12 board is connected to the Intellec 800 TrY 
port or to the Intellec 800 CRT port. The second 
variable is whether or not a parallel cable is used 
for uploading and downloading hexadecimal object 
files. 
Figures 
4A 
and 
4B 
illustrate 
the 
four 
configurations. 


In Figure 4A, the configuration 
shows the TrY 
port of the Intellec 800 system connected to the 
iSBC 86/12 
serial port using two cables and an 


iSBC 530 teletypewriter adapter. The TrY port of 
the Intellec 800 system is designed for using a 
teletypewriter as the Intellec conso~edevice. To use 
this port for communication with the iSBC 86/12 
board, the current loop TrY signal must be con- 
verted to an RS232 compatible voltage signal. This 
function is performed by the iSBC 530 adapter. 


The cable which connects the Intellec 800 system to 
the iSBC 530 adapter performs a function similar 
to the 
RS232 Up/Down 
Load 
cable described 
above. A schematic for this cable and all other 
components of the iSBC 957 package are included 
with the delivered product. 


The transfer 
rate for both commands 
and data 


when the TrY port is connected to the iSBC 86/12 
board is 110 baud. This means to download even 
moderately 
sized programs 
would 
require 
large 


amounts of time, several minutes or even hours. 
However, much faster times may be achieved by 
using the parallel ports of the iSBC 86/12 
board 


and the Intellec system for downloading program 
files. This parallel port used on the Intellec 800 
system is the output port labeled PROM which is 
normally 
used 
with 
the 
Universal 
Prom 
Pro- 
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grammer. 
A cable is connected between the In- 


tellec PROM port and the parallel I/O 
port, 11 of 


the iSBC 86/12 board. Parallel port B of the iSBC 
86/12 
board is used for the 8-bit byte transfers 


from the Intellec system to the iSBC 86/12 board, 
port A is used for the byte transfers from the iSBC 
86/12 board to the Intellec system and port C is 
used for controlling the byte transfers. A special 
status adapter piggyback board must be inserted 
into a receiver/terminator 
socket of the iSBC 86/12 


board. 
This status adapter 
circuit is required to 


provide the necessary handshaking signals from the 
iSBC 86/12 
parallel ports to the Intellec PROM 


port. 
The transfer rate achieved when downloading and 
uploading hexadecimal object files with the parallel 
cable is approximately 1,000 bytes per second. The 
time required to load 64K bytes of memory is 
approximately 2\12 minutes. 


Figure 4B shows a configuration with the Intellec 
800 CRT port connected to the serial port of the 
iSBC 86/12 board. The TTY port of the Intellec 
800 system is connected to a teletypewriter or some 
other current loop device to act as a system con- 
sole. The optional parallel load cable is also shown. 
The cables used for this configuration are the same 
as those used with the Intellec Series II Configur- 
ations. Command transfer rates require 110 baud 
because the TTY port of the Intellec 800 system is 
used for communicating with the console device. 
However, hexadecimal object files can be loaded at 
9600 baud since this operation uses only the Intellec 
to iSBC 86/12 RS232 link. 


It is also possible to download files with the parallel 
cable, this mode being somewhat faster than the 
serial download 
mode (2\12 minutes versus four 


minutes for 64K bytes of memory). Table I con 
tains a summary of the command 
and memory 
transfer rates for each of the Intellec-iSBC 86/12 
configurations. 


Comparing the Intellec 800 configurations shown in 
Table 1 and in Figures 4A and 4B it should be 
noted: 


1. Using the TTY port (Figure 4A) of the Intellec 
800 system for communications with the iSBC 
86/12 board (essentially) requires installation of 
the parallel cable and jumper modifications for 
downloading and uploading files, and thus, pre- 
vents the use of the parallel ports for other I/O 
functions. 


2. Using the CRT port (Figure 4B) of the Intellec 


800 system for communication 
with the iSBC 


86/12 board provides for a fast serial download 
capability, 
thus freeing the parallel ports 
for 


other uses. However, this configuration requires 
a teletypewriter or a CRT capable of accepting 
a current loop input signal as the Intellec system 
console. 


Table 1 


COMMAND 
AND MEMORY TRANSFER RATES FOR 


INTELLEC-iSBCTM 
86/12 CONFIGURATIONS 


INTEllEC 
SERIES 
11220/230 
SERIAL 
PORT 
TO iSBC 86/12 


INTEllEC 
BOO 


TTY PORT 


TO iSBC 86/12 


INTEllEC 
BOO 
CRT PORT 
TO isilc 
86/12 


Effective 
Command Rate 
600 
Baud 
110 Baud 
110 Baud" 


Load I Transfer 
Rate 
Serial 
9600 
Baud 
110 Baud 
9600 Baud 


Parallel 
N/A 
lK bytes/sec·· 
lK bytes/sec·- 


Approximate 
Time 
to load 64K bytes 
of memory 


Serial 
4 minutes 
5 hours 
4 minutes 


Parallel 
N/A 
2.5 minutes 
2.5 minutes 


-The actual baud rate of the Intellec-iSBC 
86/12 
link is 9600 baud, but the effective 
command 
rate is d.etermined by the slower 
Intellec- 
console serial link. 


·-Transmission 
rate over the parallel link is determined 
by the speed of the two processors 
and is approximately 
1K bytes per second. 


IV. THE iSBC 957-iSBC 
86/12 MONITOR 


PROGRAM 


The iSBC 86/12 monitor program is an EPROM 
resident program 
which facilitates debugging of 


user written programs. The monitor program used 
in the iSBC 86/12 board with the iSBC 957 pack- 
age is the same monitor program written to inter- 
face the iSBC 86/12 
directly to an RS232C data 


terminal. When interfaced directly to a terminal, 
the iSBC 86/12 board functions in a stand-alone 
environment communicating directly with the user 
via the data terminal. A user may use the monitor 
for entering small programs in hexadecimal format, 
executing 
a 
program, 
examining 
registers 
and 


memory contents, etc. 


To use the monitor program with an Intellec system, 
the proper cables must be installed and the iSBC 
957 Loader program must be loaded into Intellec 
memory and executed. The Loader program is resi- 
dent on a file named SBC86l, and when executed, 
the Loader outputs a sign-on message. Next, the 
iSBC 86/12 monitor program must be started and 
the baud rate of the iSBC 86/12 to Intellec serial 
communications link must be determined. This is 
done by pressing the RESET switch on the chassis 


Table 
2 


MONITOR 
COMMAND 
LIST 


COMMAND 
FUNCTION 
AND SYNTAX 


Load Hex 
Loads hexadecimal object file from Intellec into iSBC 
Object File 
86/12 memory using serial {51 or parallel (P) mode. 


L{SIP};< filename>[,<bias 
addr>]<cr> 


T Transfer Hex 
Transfers blocks of iSBC 86/12 memory to Intellec as 
Object File 
a hex object file using serial (5) or parallel(PI mode. 


T{XI {SIP} 
,<start addr>,<end addr>, < filename> 
I.<exec addpj<cp 


E Exit 
Exits the loader program and returns to ISIS. 


Executes one user program instruction. 


N[ <addr> 1,[[<add!». 
[*<cr> 


Transfers control of the 8086 CPU to the user program 
with up to 2 optional 
breakpoints. 


G«start addr>1L<break 1 addp 


1.<break 2 addr» 
]<cr> 


Displavs/modifies 
memory locations in byte or word 
format. 


SIW!<addr>, 
([new 
contentsU·<cr> 


Displays/modifies 
8086 CPU registers. 


X[<reg>II[<new 
contents>!,J-<cr> 


Displays contents of a memory block in byte or word 
format. 


D[W]<stan 
addr>(,<end 
addr>l<cr> 


Moves contents of a memory block. 


M<start addr>,<end addp, 
< destination 
addr><cr> 


Compares two memory blocks. 


C<start addr>, < end addr>,<destination 
addp<cp 


Searches a memory block for a byte or word constant. 


F[W}<start 
addr>,< end addr>,<data> 
< Cr> 


Performs hexadecimal addition and subtraction. 


H<data 1>,<data 2><cr> 


Inputs and displays byte or word data from input 
port. 


HWI<port 
addr>, I, J-<cr> 


Outputs byte or word data to output port. 


O[W!<port 
addr>,<data>I.<data»- 
<cr> 


Syntax conventions used in the command structure are as follows: 


(A! 
indicates that "A" 
is optional 


{AI- 
indicates one or more optional iterations of "A" 


<S> 
indicates that "S" 
is a variable 


{AIS} 
indicates "AU or "S" 


<cr> 
indicates a carriage return is entered 


Numeric arguments can be expressed as a number, the contents of a register, 
or the sum or difference 
of numbers and register contents. 
Thus, addresses 
and data can be expressed as follows: 


f <expr>: I<expr> 


<number>l<register>l<expr> 
{+ I-} 
<number>l 


<expr> {+ l-} 
<register> 


AXI 
BX 1eXI 
OX 15 P 1B PI 511 011 e5 
I 05 
155 
1E5 IIPI FL 


<digit >1< digit ><number > 


0111213141516171B191AI 
B ICI 01 EI F 


Numeric fields within 
arguments 
are entered as hexadecimal numbers. 
The 
valid range of numerical values is from 
OCIOO-FFFF. 
Larger numbers may be 
entered, but only the last four digits lor two in the case of byte values) are 
significant. 
Leading zeros may be omitted. 


An address argument consists of a segment value and an offset value separ· 
ated by a colon (:). If a segment value is not specified, the default segment 
value is the CS register value. 


containing the iSBC 86/12 board and typing two 
"U"s on the Intellec console. The ASCII uppercase 
character U has a binary pattern of alternating ones 
and zeros, the iSBC 86/12 monitor uses this pattern 
to determine the baud rate of the serial link. After 
the baud rate has been determined, the monitor 
program outputs a sign-on message to the console. 
An example of 
loader 
program 
execution 
and 


monitor program initialization is shown below (user 
entered characters are underlined). 


:FI:SBC861 
ISIS-II iSBC 86/12 LOADER, Vx.x 
(user resets iSBC 86/12 board and types two "U"s) 
!SBC 86/12 MONITOR, Vy.y 


The monitor prompts with a period "." 
when it is 


ready for a command. The user can then enter a 
command file, which consists of a one- or two- 
character command followed by zero, one, or more 
arguments. The command may be separated from 
the first argument by an optional single space; a 
single comma is required as a delimiter between 
arguments. The command line is terminated by a 
carriage return or a comma depending on the com- 
mand, and no action takes place until the command 
terminator is sensed. The user can cancel a com- 
mand before entering the command terminator by 
pressing any illegal key (e.g., rubout or Control-X). 


Table 2 contains a summary of the loader and 
monitor commands. These commands will not be 
explained in detail; instead, the next section of the 
application note will show examples of using these 
loader 
and 
monitor 
commands. 
The iSBC 957 


User's Guide referenced at the front of this docu- 
ment does, however, contain a complete description 
of each of the monitor and loader commands. 
Table 3 contains a list of the 8086 hardware registers 
and abbreviations used by the monitor program. 


Table 
3 


8086 CPU 
REGISTERS 


REGISTER NAME 
ABBREVIATION 


Accumulator 
AX 


Base 
BX 


Count 
CX 


Data 
OX 


Stack 
Pointer 
SP 


Base Pointer 
BP 


Source 
Index 
SI 


Destination 
Index 
01 
Code Segment 
CS 


Data Segment 
OS 
Stack Segment 
SS 


Extra Segment 
ES 


Instruction 
Pointer 
IP 


Flag 
FL 


ON-BOARD 
{ 
FFFFF" 
39 


EPROM 
MONIT,OR 
PROGR~M 


38 
j8K bytes} 
FEOOOH 


37 


36 


35 


34 


33 


AVAILABLE 
32 
8000" 
------ 
USER 
------ 


AREA 
31 


ON-BOARD 
lCOH 


RAM 
INITIAL 
USER STACK 


132K bytes) 
130" 


MONITOR 


DATA 
AREA 


AD" 


INTERRUPT 
VECTORS 


0-39 


0" 


INTR 7 


INTR 6 


INTR 5 


lNTR 
4 


. 
INTR 3 


INTR2 


INTR 
1 


INTR 0 


9C" 


98" 


94" 


90" 
8259A 
PIC 


BC" 
VECTORS 


88" 


84" 


80" 


RESERVED 
FOR 
FUTURE 
USE BY 
INTEL 


Interrupt 
on Overflow 
10H 


One-Byte 
Intr Instruction 
CH 


Non·Maskable 
Inlr 
8H 


Single 
Step 
4H 


Divide 
by Zero 
0H 


Figure 5 contains 
a memory map of the iSBC 
86/12 
memory with the monitor program. 
Note 


that the monitor uses the top 8K bytes of memory 
for its program code and the first 384 bytes of 
memory (locations ~ hex to l7F hex) for monitor 
and user stack, data and interrupt vectors. When 
the monitor program is reset, the segment registers, 
the IP and the flags are set to 1/); and the SP is set 
to ~lCI/JH allowing 64 bytes for the user's stack. If 
64 bytes is not sufficient for the user's application 
program, the SP should be set to some other value. 
The monitor program sets the single-step, one-bYte 
instruction trap and non-maskable interrupt vectors 
to monitor entry points. The monitor also sets the 
8259A Priority Interrupt Controller to fully nested 
mode with level I/) at the highest priority and all 
interrupts 
unmasked. 
The eight interrupt 
vector 
addresses for ~he 8259A are also set to addresses in 
the monitor. User programs may change the 8259A 
interrupt 
vectors to interrupt 
service routine ad- 
dresses within the user programs; it is not necessary 
for users to program the 8259A chip directly. When 
an interrupt 
occurs, control passes to either the 
monitor or directly to user code depending on the 
address stored in the vector location. When the 
monitor responds to an interrupt, it acknowledges 
the interrupt and displays the interrupt level, CS 
and IP register values and next instruction byte on 


the system console (e.g., 1=3 
@ lOO:230FF5). 


When a user requests a breakpoint 
with a "G" 


command, 
the 
monitor 
inserts 
the 
single byte 


instruction trap instructions (INT 3) in the location 
where the breakpoint is requested. It is also possible 
for the user to code an INT 3 instruction in his 
program. When a user coded INT 3 instruction is 
executed, the monitor will be re-entered and a line 
with the format 
@<CS Value>:<IP Value> <In- 
struction byte> will be displayed (e.g., @l200:3F02 
F5). 
. 


Included on the diskette with the Loader program 
are two libraries containing I/O 
routines for the 


console. The library files are named SBCIOS.LIB 
and SBCIOL.LIB; 
they contain similar routines. 


The routines in SBCIOS.LIB 
are written to be 


called with intrasegment subroutine calls, a PL/M- 
86 module 
compiled 
with the 
"small" 
control 


generates 
this 
type 
of 
call. 
The 
routines 
in 


SBCIOL.LIB are written to be called with interseg- 
ment subroutine calls, a PL/M-86 
module com- 


piled with either the "medium" 
or "large" control 


generates this type of call. 


The console input output 
routines, 
CI and CO, 


contained in the library should be used when per- 
forming character input and output on the console. 
Example PL/M-86 calls to the two routines are: 


CI: 
PROCEDURE BYTE EXTERNAL; 
END CI; 


CO: PROCEDURE (X) EXTERNAL; 
DECLARE X BYTE; 
END CO; 


DECLARE INPUT$CHAR, 
OUTPUT$CHAR 
BYTE; 


General Comments 
on Use of the iSBC 957 Package 


1. If the iSBC 86/ 12 board is reset any time after 


the initial baud rate search, it is not necessary to 
reload 
the iSBC 957 Loader 
program 
or to 


download the program code a second time to the 
iSBC 86/12 
board. 
It is only necessary to re- 


establish the communications link by typing two 
"U"s for the baud rate search. 


2. The iSBC 86/12 
board should not be plugged 


into an available card slot in an Intellec chassis; 
a separate chassis should be used. There are at 
least three reasons for this: 


a. There is only one RESET signal available on 


the Intellec system bus. Thus, each processor 
may not be reset independently. This means 
that the iSBC 86/ 12 board cannot be reset 
without re-booting the ISIS-II operating sys- 
tem and restarting the iSBC 957 Loader. 


b. The Intellec system uses five of the eight avail- 


able interrupts on the system bus. This severely 
restricts the range of interrupts 
available to 


the iSBC 86/12 board. Also, the iSBC 86/12 
board cannot turn-off the interrupt lamps on 
the Intellec front panel. 


c. The iSBC 86/12 board may address up to 1 
Megabyte of memory using a 20 bit address. 
Many Intellec systems contain boards which 
generate and decode only the low order 
16 


address bits. For example, the iSBC 016 mem- 
ory expansion 
board 
and the 
Intellec 800 


monitor PROMs only decode 16 address bits. 
Memory expansion above 64K bytes in these 
systems is difficult since the boards which de- 
code only 16 bits will force "holes" 
in the 


address space above 64K. 


3. The iSBC 86/12 
board 
is delivered with two 


inputs to the 8259A Priority Interrupt Controller 
connected. Interrupt request 2 (IR2) is connected 
to the counter ~ output of the 8253 Program- 
mable Interval Timer. IR5 is connected to the 
INT5/signal 
of the MULTIBUS System Bus. If 


these interrupts are not desired, the wire wrap 
jumpers making the connections should be re- 
moved from the iSBC 86/12 board. A particular 
problem may exist with the counter ~ connection 
to IR2. If the 8253 counter ~ is not specifically 
initialized with software, a low frequency square 
wave output will exist at counter ~'s output. This 
may cause unwanted interrupts when interrupts 
are enabled by user programs. 


4. If the iSBC 86/12 board is used in a system with 


expansion boards, it is important that the MUL- 
TIBUS bus exchange pins be properly jumpered. 
For example, if the iSBC 86/12 
board is used 


with an iSBC 032 expansion memory board in a 
system, 
the 
BPRN / MULTIBUS pin for the 


iSBC 86/12 board should be grounded. 


In addition, if any interrupts are used with the 
iSBC 86/12 
board 
the 
BPRN / pin must be 


grounded. This is true in both single and mul- 
tiple board systems. 


5. Certain user systems require more than one single 


board computer in the system for performing the 
functions required by the application. The MUL- 
TIBUS System Bus has been specifically designed 
to permit multiple CPU boards to communicate 
and to share system resources. 
However, 
de- 
bugging systems with multiple CPUs has always 
posed somewhat of a problem. The iSBC 957 
package provides a solution to this problem. The 
serial cable which connects 
the iSBC 86/12 


board to the Intellec system may be removed 
after the program has been downloaded to the 
iSBC 86/12 board. A console CRT may then be 
connected directly to the iSBC 86/12 board and 
the monitor program may be used to debug the 
program 
running 
on the board. 
Other 
iSBC 


86/12 boards may also be downloaded from the 
Intellec system and then switched to their own 
local terminals. An 8-bit processor board, such 
as the iSBC 80130 board, may also be included 


in the system and ICE-85™ may be used for 
debugging the iSBC 80/30 program concurrently 
with 
the 
iSBC 86/12 
programs. 
Using 
this 
scheme, it is possible to debug a system which 
has several CPU boards by setting breakpoints 
and using other debugging features on each of 
the individual CPUs. 


V. MATRIX MULTIPLICATION 
EXAMPLE 


To illustrate how the iSBC 957 package can be used 
to assist in the writing and debugging of 8086 pro- 
grams on the iSBC 86/12 board, an example pro- 
gram of a matrix multiplication will be presented. 
The example chosen has been intentionally kept 
simple and straightforward. 
The emphasis of this 
section will be to document the steps required to as- 
semble, compile, link, locate and debug software 
using an Intellec system, the iSBC 957 package and 
the iSBC 86/12 board. Part of the example will be 
written in 8086 assembly language and part in PL/ 
M-86. 


The main program 
is written in PL/M-86. 
The 
main program 
first performs 
some initialization 


and the matrix multiplication, 
then the program 


calls an assembly language procedure (subroutine), 
a PL/M-86 
procedure and the console output pro- 
cedure CO supplied in the I/ 0 library on the iSBC 
957 diskette. 
A flow diagram 
for the example 
program is shown in Figure 6. 


Explanation of the Program Code 


The program code is contained in three software 
modules 
EXECUTION$VEHICLE, 
FIND, 
and 


SBCCO. 
EXECUTION$VEHICLE 
contains 
the 
main program coded in PL/M-86 
and the binary 
to ASCII 
conversion 
procedure 
BIN$DEC$ASC 


also coded in PL/M-86. 
The module FIND con- 
tains the assembly language procedure FIND$MX 
which searches a matrix for its maximum value. 
The module SBCCO resides in the library of con- 
sole I/O routines supplie? with the iSBC 957 pack- 
age. The procedure 
CO will be used from this 
library. 


The program code for the EXECUTION$VEHICLE 
and FIND modules will be explained in the follow- 
ing paragraphs. 
Appendix B contains compilation 


and assembly listings for the two modules; also 
contained in Appendix B is a memory and debug 
map for the linked modules. The listings contain 
circled reference letters (e.g., @) which are referred 
to by the code description below. The listings in the 
appendix have been printed on fold-out pages so 
that they may easily be seen when reading the text. 


Initialize 


XSROW 
& YSRQW 


Matrices 


Multiply 
Matrices, 
store result in 
ZSROW 


Output 
MAX 
value on 
terminal 
using 


CO routine 


Figure 6. 
Flow Diagram 
of Matrix 
Multiplication 
Example 


Much of the description given below assumes that 
the reader is familiar with the PL/M-86 
language 


and compiler, the 8086 assembler, and the link and 
locate program QRL86. It is recommended that the 
reader have at least a cursory knowledge of these 
subjects. The Intel literature for these subjects is 
listed near the front of this application note. 


The EXECUTION$VEHICLE 
Module 
® The first section of the module includes intro- 


ductory comments and then statements to de- 
clare the matrices, other variables, and pro- 
cedures used in the program. 
Note that the 


matrix dimensions are declared using the literals 
M, N, and P which are initially set to 6, 5, and 
3. Later in this note, other values for M 
N 


and P will be used. 
' 
, 


® The next section of code contains the state- 


ments which initialize the two matrices that will 
be multiplied X$ROW and Y$ROW. 


As a result of this initialization, the two ma- 
trices will contain values as shown in Figure 7. 


0 
0 
0 
0 
0 
0 
-1 
-2 


-1 
-2 


2 
2 
2 
2 
0 
-1 
-2 


3 
3 
3 
3 
0 
-1 
-2 


4 
4 
4 
4 
4 
0 
-1 
-2 


5 
5 


X$ROW(6X5) 
Y$ROW 
(5X31 


Figure 7. 
X$ROW 
and Y$ROW 
Matrices 
After 
Initialization 


© The next program section performs the matrix 
multiplication. The algorithm required to mul- 
tiply two matrices X and Y, storing the result in 
a third matrix Z is: 
n 


Zmp = L. Xmi *Yip 
i = I 


Assuming X to be 6X5 matrix and Y a 5X3 
matrix then 


Zll= XllYll + X12Y21 + X13Y31 +X,.X", + X"Y" 
Thus, the upper left term is equal to the sum of 
the products of the top row of the X matrix 
times the left column of the Y matrix. The re- 
sult that is obtained by multiplying the two 
matrices X$ROW and Y$ROW after they are 
initialized as explained 
above, 
is shown 
in 


Figure 8. 


0 


-5 
-10 


-10 
-20 


-15 
-30 


-20 
-40 


-25 
-50 


Figure 8. 
Result 
of Multiplying 
the Initialized 
Matrices 
X$ROW 
and Y$ROW 


® The 
external 
assembly 
language 
procedure 


FIND$MX is called to determine the maximum 
value in the matrix. The procedure is a typed 
procedure and returns the maximum value to 
the calling program which stores it in the inte- 
ger variable MAX. 


® The maximum value is then converted to a six 


(6) digit ASCII character 
string by the pro- 


cedure BIN$DEC$ASC. The character string is 
stored in the array MAX$ASC$ARRA Y, which 
contains the sign of the number and five (5) 
digits for the magnitude. 
® Finally, the characters "MAX VALUE =" are 


output on the system console followed by the 
6 ASCII characters containing the maximum 
value. The PL/M-86 
built-in procedure SIZE 


returns the number of bytes of the array TEXT 
as a word value. The PL/M-86 
built-in pro- 


cedure SIGNED changes the type of the value 
from WORD to INTEGER. This is required so 
that the type of the arguments in the DO state- 
ment agree. The console output procedure CO 
is used to output the characters on the system 
console. 
© Also contained in the module MATRIX.PLM 


is the binary to ASCII conversion procedure 
BIN$DEC$ASC. The first portion of the code 
contains 
the comments 
explaining the para- 


meters and the calling sequence followed by the 
declarations. Note that the address of the array 
where the characters are to be stored is passed 
to the procedure and that the characters will be 
stored in the array using based variables. The 
next section of the code stores either a + or - 
sign in the first character position of the ASCII 
array and stores the absolute value of VALUE 
in the variable TEMP. Finally, the binary value 
is converted 
to 
ASCII 
using the 
algorithm 


explained in the comments. The MOD operator 
returns the remainder of the division by 10. The 
UNSIGN 
built-in 
procedure 
is required 
to 


change the type of the expression from INTE- 
GER to WORD. 


The FIND Module 
® The FIND module contains the assembly lan- 


guage procedure 
FINDMX. 
The calling se- 


quence and the parameters are explained in the 
comments at the beginning of the listing. Note 
that 
the label FINDMX 
has been declared 


PUBLIC so the link program 
can fill in its 


address in the CALL statement in the main 
program of module EXECUTION$VEHICLE. 


CD The FIND module will contain three segments: 


a data segment, a stack segment and a code 
segment. It will be both convenient and prag- 
matic to append these three segments to the 
code, data and stack segments created by the 


compiler 
for 
the 
EXECUTION$VEHICLE 


module. To accomplish this, the three segments 
must be given the same SEGMENT and CLASS 
names as those given these segments by the 
compiler. The SEGMENT and CLASS names 
used by the compiler are CODE, DATA, and 
STACK. The GROUP statements are used to 
place the segments DATA and STACK in the 
group DGROUP and the segment CODE in the 
group CGROUP. These group definitions con- 
form with the group definitions generated by 
the PL/M-86 
compiler when the SMALL size 


control option is used. A group is a collection 
of segments which requires less than 64K bytes 
of memory. 


The ASSUME directive informs the assembler 
that the DS and SS registers will contain the 
base address of DGROUP and the CS register 
will contain the base address of CGROUP. 
This information will be used by the assembler 
when constructing machine instructions. 
(1) The first segment appearing in the module is 
the data segment. The order of the segments is 
arbitrary, although it is recommended that the 
data segment precede the code segment to mini- 
mize forward references to variables which may 
cause the assembler to generate longer instruc- 
tion 
codes. 
The 
data 
segment 
is declared 
PUBLIC, aligned on a WORD boundary and 
given both a segment and class name of DATA. 
Then follows the contents of the segment. In 
this particular example, only one word of stor- 
age is required. The ENDS directive indicates 
the end of the segment. 


® Next comes the stack segment which is given 


the segment name of STACK, the combine- 
type attribute of STACK and the class name of 
STACK. The combine-type attribute of STACK 
assures that the stack storage required in this 
module will be appended to the storage re- 
quired in the PL/M-86 
compiled modules. Two 


bytes of stack are required by the code in this 
module, however, the monitor uses 13 words of 
stack when breakpoints and interrupts are used. 
Therefore, 14 words are reserved for the stack. 


Finally comes the code segment. The code seg- 
ment has been given a segment name and class 
name 
of 
CODE 
and 
a 
group 
name 
of 


CGROUP, 
and has been declared PUBLIC. 
The alignment attribute of BYTE is specified 


since it is desired that 
the code from 
this 


module be appended directly to the code from 
other modules without gaps between the code 
modules. 


The assembly language code follows next. The 
code for the procedure must be enclosed be- 
tween a pair of PROC, ENDP statements. The 
PROC statement is given the label FINDMX 
and specified as a NEAR procedure indicating 
it will be called with a near (intra-segment) 
CALL instruction and not a far (inter-segment) 
CALL instruction. 


The comments at the beginning of the module 
and adjacent 
to the program 
statements ex- 
plain the 
function 
being performed 
by the 
assembly language code. 


The SBCCO Module 
@ The console output procedure CO is contained 
in the object module SBCCO of the library file 
SBCIOS.LIB. SBCIOS.LIB is part of the iSBC 
957 package I/O libraries. The calling sequence 
and parameters 
for CO may be seen in the 
external 
procedure 
declaration 
in the 
EXE- 


CUTION$VEHICLE module. 


Compiling the EXECUTION$VEHICLE 
Module 


The EXECUTION$VEHICLE 
module is stored on 
a file named MATRIX.PLM 
on disk device :FI:. 


To compile the module, the following command 
line is used: 


- PLM86 :Fl:MATRIX.PLM 
DEBUG 


This command line will cause the module stored in 
the file :Fl :MATRIX.PLM 
to be compiled. The 
object code generated will be stored in a file with 
the default name :Fl :MATRIX.OBJ and the listing 
generated will be stored in a file with the default 
name :Fl:MATRIX.LST. 
To override the default 
object and listing files, the NOOBJECT and NO- 
LIST compiler control switches can be used. File 
names for the listing and object files may also be 
specified in the command line. The DEBUG com- 
piler control switch causes the compiler to generate 
extra symbol and line number information 
which 


will be used during debugging of the program. A 
listing of the compiled EXECUTION$VEHICLE 
module is contained in Appendix B. 


To aid in the debugging of the program, 
the 
module was compiled a second time with the fol- 
lowing command line: 


- PLM86 :Fl:MATRIX.PLM 
NOOBJECT 
CODE DEBUG PRINT (:Fl:MATRIX.xLS) 


This command line specified that no object file is to 
be created and a listing file should be stored in the 
file :Fl:MATRIX.xLS. 
The CODE compiler con- 
trol switch causes the compiler to list the assembly 
language statements which the compiler has gener- 
ated for each line of PL/M 
code. The listing stored 
in the file MATRIX.XLS is contained in Appendix 
C. 


Assembly of the FIND Module 


The assembly language module FIND is stored on a 
file named FIND.ASM, 
to assemble this module 
the following command line is used: 
' 


ASM86 :Fl:FIND.ASM 
DEBUG 


This command line will cause the FIND module to 
be assembled with the object code stored in the 
default file :Fl :FIND.OBJ and the listing stored in 
the default file :Fl :FIND.LST. The listing of the 
assembled FIND module is contained in Appendix 
B. 


Linking and Locating the Object Module 


To link and locate the object modules, the QRL86 
program will be used. The QRL86 program per- 
forms both the linking and the locating of the 
object modules in a single step. QRL86 is primarily 
designed for the debugging stages of program devel- 
opment. Some applications may require the extended 
capabilities of the separate LINK and LOCATE 
programs when the final link and locate is per- 
formed. 
The command 
line used to invoke the 


QRL86 program is: 


QRL86 :Fl:MATRIX.OBJ, 
:Fl:FIND.OBJ, 


SBCIOS.LIB ORIGIN (lOOOH) 


This command line will cause QRL86 to link the 
code from the three modules and to locate the 
resultant absolute object module starting at location 
1000 hexadecimal. The iSBC 86/12 
monitor uses 


the first 180H bytes of memory for the monitor 
stack, data and interrupt vectors, lOOOHwas chosen 
as a convenient starting address for the program. 
The absolute object code will be stored in a default 
file :Fl:MATRIX 
(note no file name extension is 


used). By default, .the memory and debug maps 
which are generated are stored in the file :Fl :MA- 
TRIX.MPQ and are contained in Appendix B. 
® The memory 
map contains 
the starting 
ad- 


dresses 
and 
sizes of 
the 
CODE, 
CONST, 


DATA, STACK and MEMORY segments of 
the object module. Note that the start address 


for the program is specified as (~lWH, ~2H) 
indicating a CS value of ~lWH 
and an IP 


value of m2H 
or an absolute value of ~HW2H. 


The first two bytes of the code segment contain 
address values which the code generated by the 
compiler will use for setting up the DS and SS 
registers. The memory map shows the code 
segments from the three modules collected into 
the group CGROUP. The code segment from 
,the EXECUTION$VEHICLE 
module is given 


the segment and class names of CODE and is 
put into CGROUP by the PL/M 
compiler. To 


assure that the code segment from the FIND 
module is concatenated with the code segment 
from the EXECUTION$VEHICLE 
module the 


identical class, segment and group names were 
specified in the SEGMENT and GROUP state- 
ments in the FIND module. Next, the group 
DGROUP 
is shown 
in the 
memory 
map. 


DGROUP 
contains 
4 
segments 
labelled 


CONST, 
DATA, 
STACK 
and 
MEMORY. 


Putting all of these segments in the same group 
tells the linker that they will all be in the same 
64K block of memory. The SMALL size con- 
trol option of the compiler, which was invoked 
by default, creates CGROUP, DGROUP, 
and 


the segments contained in them. 
® The debug map contains the memory address 


of variables, 
instruction 
labels and the ad- 


dresses of each code line of the PL/M-86 
module. Notice that the variable storage labels 
have their addresses specified in the format (DS 
register value, displacement). For example, the 
variable TEMP has an address of DS=~12AH, 
displacement = mCH 
or an absolute address 


of ~136H. Instruction labels and line numbers 
use the format (CS register value, IP register 
value). Thus, line number six (6) in the module 
EXECUTION$VEHICLE 
has 
the 
address 


CS=01~H, 
IP=~B5H 
or ~11B5H. 


Object to Hex Conversion 


Before downloading the program to the iSBC 86/12, 
the format of the object module must be converted 
from 
the absolute 
object module format 
which 


QRL86 creates to a hexadecimal/ASCII representa- 
tion of the object module. This is done using the pro- 
gram 01-186with the following command line: 


OH86 :FI:MATRIX TO :FI:MATRIX.HEX 


Downloading and Debugging the Program 
The hardware configuration used for debugging the 
matrix multiplication example program code was 


an Intellec Series II Model 230 development sys- 
tem, the iSBC 957 package, an iSBC 86/12 board, 
and an iSBC 660 system chassis. What follows is 
the 
system-user dialog 
for 
a typical debugging 
session. 


The first step required is to bootstrap 
load the 
ISIS-II operating 
system by hitting the RESET 


switch of the Intellec. The Intellec resident loader 
software is then loaded and executed. Throughout 
the dialog which follows operator entered charac- 
ters will be underlined: 


ISIS-II, 
V3.4 
-~ 


ISIS-II 
Isac 
86/12 
LOADER, Vl.2 


To initialize the iSBC 86/12 monitor, the user must 
hit the RESET switch on the iSBC 660 chassis and 
type two "U"s on the system console. The monitor 
program will output a line on the console when it is 
properly initialized. 


The monitor command "X" is typed to check that 
the monitor is properly operating and to examine 
the contents of the 8086 registers. 


. x 
AX::0000 
6X:::0000 
CX=I:'l000 DX::0000 
SP=01C0 
BP=00e0 
51=0000 


Dl=0000 
C5:::0000 
D5=0000 
55:::0000 
E5=0000 
IP=0000 
FL=""00 


To 
download 
the hex object 
file to the iSBC 
86/12, 
the "L" 
command 
is used. Because an 
Intellec Series II Model 230 is being used, a serial 
download 
is specified. 
The 
hex 
file 
name 
is 
MATRIX. HEX which is resident on disk device 
:FI:. 


The "X" 
command is used again to examine the 
CPU registers. Note that the monitor has changed 
the contents of the CS and IP registers to the value 
of the starting address of the program. 


• X 
AX="""" 
BXz~IIHI0 
CX""0000 
oX=IHH;" 
SP=01CI:1 
BP=0000 
51=0000 


01::0000 
C5=0108 
DS::"~~0 
55=000" 
E5:::0000 
IP=0002 
FL=0000 


The "0" command is next used to display the first 
WI bytes of the program code. Unless another seg- 
ment register is specified, the display command 
assumes all addresses specified are relative to the CS 
register. Thus, the code displayed will be from abso- 
lute addresses 1000through 1100.The program code 
displayed may be compared with program code gen- 
erated by the PLlM-86 compiler shown in Appendix 
C, code line 36. 


. De, 100 


0000 
2A 01 
FA 2E 8E 
16 
00 
00 
BC D0 00 
8B EC 16 
IF 
FB 


0010 
C7 
06 
BE 00 
80 
00 
81 
3E 
8E 
08 
05 
88 
7E 03 
E9 
3C 


0020 
80 
C7 
06 
90 
00 
00 
00 
81 
3E 
90 
80 
04 
00 
7E 03 
E9 


0030 
22 
00 
8B 06 
BE 00 
B9 
0A 08 
F7 
E9 8B 36 
98 
00 
D1 


0048 
E6 
89 
C3 
8B 0E 
8E 00 
89 
88 
10 
00 
81 
06 
90 
00 
01 


0058 
00 
E9 03 
FF 
81 
06 
8E 00 
01 
00 
E9 
B9 FF C7 
06 
8E 


0060 
00 
00 
00 
81 
3E 8E 
00 
04 
00 
7E 03 
E9 
40 
00 
C7 
06 


0070 
90 
00 
80 
80 
81 
3E 90 
00 
02 
00 
7E 03 
E9 
26 
00 
8B 


0080 
06 
90 
00 
F7 
D8 50 
8B 86 
8E 00 
B9 
06 
00 
F7 
E9 
8B 


0090 
36 
90 
00 
D1 E6 
89 
C3 
59 
89 
88 
4C 00 
81 
06 
90 
00 


00A0 
01 
00 
E9 CF 
FF 81 
06 
8E 00 
01 
00 
E9 
B5 FF C7 06 


00B0 
92 
00 
00 
00 
81 
3E 92 
80 
02 
00 
7E 03 
E9 
8C 00 
C7 


00C0 
86 
8E 00 
00 
00 
81 
3E 8E 
00 
05 
00 
7E 03 
E9 72 
00 


0000 
88 
06 
8E 
00 
B9 06 
00 
F7 
E9 
8B 36 
92 
00 
D1 E6 
89 


00E0 
C3 C7 
80 
6A 00 
00 
00 
C7 
06 
90 
00 
00 
00 
81 
3E 
90 


0aFe 
00 
04 
00 
7E 03 
E9 
41 
00 
Be 
06 
BE 00 
89 
SA 00 
F7 


0100 
E9 


The PL/M-86 
compiler ends the main program in 
the EXECUTION$VEHICLE 
module with a halt 


instruction. After execution of the program it is 
more desirable to return to the monitor. To ac- 
complish this, an INT 3 instruction 
(code=CC) 


will be substituted for the halt instruction (code= 
F4) at the address of IB4H relative to a CS value 
of lOOH. First the "0" command is used to verify 
the address of the halt instruction, then the "S" 
command is used to change the instruction to an 
INT 3 instruction. 


.0184 
elB"4F4 
.5184, 
F4- 
~ 


To execute the PL/M-86 
main program, the "0" 


command is used. After the "0" is typed, the 
current contents of the IP are output, followed by 
the contents of the byte pointed to by the IP. A 
new value for the IP or breakpoint addresses may 
be specified before a carriage return <CR> is typed. 
[n this example, only a <CR> is typed. 


.G 
0002- 
FA 


MAX 
Vi\LUE 
= 
-9"050 


@8100,81B5 
55 


The program executes and outputs the maximum 
value of the matrix calculated. The INT 3 instruc- 
tion is executed which causes a return 
to the 


monitor. 
The monitor 
types out an at-sign (@) 


followed by the CS and IP register values and the 
first byte of the instruction following the INT 3 
instruction. 


The "X" 
command is typed to examine the CPU 


registers. Note that the program has set both the SS 
and OS registers to ~12A. (~12A~H is the address 
of the OOROUP as shown 'in the memory map.) 


.x 
AX=(HDe 
BX:::000S 
CX=01:10A 
DXz0iHHJ 
Sp::00D0 
Bp:::00D0 
51:::000 
01=0006 
C5=0100 
DS::012A.. SS=012A 
E5=01300 
Ip::l:~185 
FL"'F20, 


display has been specified by using the "DW" 
Command and that the addresses have been speci- 
fied relative to the DS register. The addresses of 
X$ROW, Y$ROW, and Z$ROW may be found in 
the debug map given by QRL86. Note that the 
values stored in the matrices are the same as those 
shown in Figures 8 and 9. 


.DW 
DS:10,4A 
0010 
0000 
0000 
0000 
0000 
0000 
0001 
0001 
0001 


0020 
0001 
0001 
0002 
0002 
0002 
0002 
0002 
0003 


0030 
0003 
0003 
0003 
0~"3 
0004 
0004 
0004 
0004 


0040 
0004 
0005 
0005 
0005 
0005 
0005 


.m'l05:4C,68 
004C 
0000 
FFFF 


~050 
FrE'£: 
000" 
FFFF 
FFE'E 
0iOI:10 FFFF 
FrE'E 
1i100'" 
11060 
FFFF 
FFFE 
0000 
FFFF 
PFFE 


.DW 
DS:6A,8C 


006A 
0"00 
0tJ0~ 
0000 


0070 
0000 
PFE'S 
FFFG 
01000 
FFF6 
FFEe 
0iHJ0 
FFFI 


kl080 
FFE2 
\:l000 
f'fEC 
FFDS 
""00 
FFE? 
FreE 


The "0" Command is used to reset the IP register 
to the start address of the program 
(1/11>2) and to 


specify a breakpoint at address ~AEH, which is the 
address of statement 
57 of the main program. 
Statement 57 is the point in the program after the 
X$ROW and Y$ROW matrices have been initial- 
ized, 
but 
before 
the 
matrix 
multiplication 
is 


performed. After the o;;CR5is typed, the program 
executes until the breakpoint 
is encountered. 
At 


this point, the monitor outputs a line specifying 
the number 
of the breakpoint, 
the CS and IP 


values and the first byte of the next instruction to 
be executed. 


.~ 
fiHB5- 
55 
002,AE 


BRI 
@0100,00AE 
C7 


Next, the single-step capability is used with the 
"N" 
command to execute single instructions. At 


any time, 
CPU 
registers may be examined 
or 


changed. In this example, the "X" 
command is 


used. Execution of succeeding instructions is caused 
by typing a comma (,). 


.~ 
"0AE- 
C7 
.L 


0084- 
Bl 
, 
008A- 
7£ ~ 
00BF- 
C7 - 


.X 


AX=0018 
eX=0018 
CX=FFFE 
DX::0000 
SP=00D0 
BP=00D0 
SI=lHHI4 


D1=0006 
C5=011:''10 D5=0121\ 
55=0121\ 
£5=0000 
!P=00BP 
FL=F'293 


.); 
008F- 
C7 
.!. 
00C5- 
81 
, 
1!HICB- 
7£ 
- 


The contents of the X$ROW and Y$ROW matrices 
are examined and changed with the "SW" 
(sub- 


stitute word) command. 
If a comma (,) is typed 


after the contents of memory are displayed, then 
the contents are left unchanged and the next word 
of memory is displayed. If a value followed by a 
comma or <.CR2 is entered, then the contents are 
changed. 
If a <CR> is entered, 
the substitute 


0~~co~~11_ 
~001- 
! 


001E 
0001- 
il 
.sw 
05:51\, 
FFFF- 
.J. 


005C 
FFFE- 
.1. 
005E 
0000- 
~ 
0060 
FFFF- 
§J: 


After 
the 
matrices 
are 
modified, 
execution 
is 


resumed with the "0" command. The max value is 
output and the INT 3 instruction executed. Finally, 
the contents of the 3 matrices are displayed. 


.g 00C8- 
7E 


MAX 
VALUE 
= 
+00430 
@0100,0185 
55 


.OW OS,10,8C 
0010 
0000 
0000 
0000 
0000 
0000 
0001 
0001 
0010 


0020 
0001 
0001 
0002 
0002 
0002 
0002 
0002 
0003 


0030 
0003 
0003 
0003 
0003 
0004 
0004 
0004 
0004 


0040 
0004 
0005 
0005 
0005 
0005 
0005 
0000 
FFFF 


0050 
FFE'E 
liHU30 
FFFF 
FFE'E 
9009 
FFFF 
FFE'E 
~HHI0 


0060 
0064 
FFE'E 
0090 
FFFF 
PFE'E 
ilhHl0 
':l000 
000~ 
0070 
0000 
0051 
FFOB 0000 
00C0 
FFEC 0~00 
0120 


i108~ 
FFE2 
i1000 
0180 
FF08 
000., 
01E0 
FFeE 


Expanding the Example Program's 
Memory Requirements 


To illustrate how the iSBC 86/12 
board may be 


used for executing 8086 programs 
which require 


large amounts of RAM, the example program will 
be modified. The matrix dimensions of the example 
will be changed from values of 6, 5 and 3 for the 
literal symbols of M, N, and P to values of 100, 
50, 70. The three matrices will then be of size 
l00X50, 
50X70, and 
l00X70. 
The memory 
re- 


quired for these matrices is 15.5K words or 3IK 
bytes. 
The 
data, 
constant, 
stack 
and 
memory 


segments 
which 
are 
contained 
in 
the 
group 


DOROUP will now comprise almost 32K bytes of 
memory. 


The extra memory requirements will be supplied 
by using an iSBC 032 board with the iSBC 86/12 
board in the iSBC 660 chassis. The iSBC 032 board 
is a 32K byte RAM board which is compatible 
with both 8- and 16-bit CPU boards. 
The base 


address of the board may be selected anywhere in 
a 0 to 1 megabyte range on any 16K byte boundary. 
8- or 16-bit data transfers may be selected. The 
iSBC 032 board will be jumpered to respond to 
addresses in the 512K or 544K address space (20 
bit hex address range to 8~H 
to 87FFFH). This 


will illustrate the capabilities of the 8086 to access 
a 20-bit, 1 megabyte address range. 


One other modification is required to the program. 
The magnitude of the numbers which would result 
from multiplying matrices of this size would great- 
ly exceed the capacity of the 16-bit integer storage, 
even with the two matrices initialized to the small 


values they presently contain. To keep the example 
simple, the initialization values will be changed so 
all elements of the X$ROW matrix are set equal to 
2 and all elements of the Y$ROW matrix are set 
equal to 3. The result of the multiplication should 
make all the elements of Z$ROW equal to 300. 


The modified lines of program 
code are shown 


below. 


/* 
MATRIX 
DI!"tENSIONS. 
*/ 
DECLARE 
M LITERALLY 
I HH' 
I ; 


DECLARE 
N 
LITERALLY 
• 50 
I ; 


DECLARE 
P 
LITERALLY 
'70 
I ; 


36 
00 
I 
- 
0 TO (M-l), 


37 
DOJ-0TO(N-l), 
38 
. 
X$ROW(I) 
.COL(J) 
2, 
39 
END, 
40 
END; 


41 
DOI-0TO(N-l), 
42 
00 
J 
= 0 TO (P-l), 
43 
Y$ROW(I) 
.COL(J) 
= 
3, 
44 
END, 
45 
END, 


The EXECUTION$VEHICLE 
module must be re- 


compiled and then the three program modules must 
be linked and located using the QRL86 program. 
Specifying the SEGMENTS option of QRL86, the 
origin of the CODE segment which is in the group 
CGROUP is set at l000H, as in the first example. 
However, 
the 
origin 
of 
the 
CONST, 
DATA 


STACK and MEMORY segments which make up 
the group DGROUP is set at 80000H. 


QRL86 :Fl:MATRIX.OBJ,:Fl:FlND.OBJ, 
SBCIOS.LIB SEGMENTS (CODE(lOOOH), 
CONST (80000H), DATA STACI\, MEMORY) 


The memory map generated by QRL86 shows the 
CGROUP ,having a st~rt address of 01000H and 
the DGROUP having a start address of 80000H. 


INVOKED 
BY: 
QRL86 
:Fl:MA'rRIY.OBJ,:Fl:FINO.OBJ,SBCIOS.LIB 
, 
SEGMENTS 
(CODE 
(100"") 
,CQNST 
(B'Ule,,") 
, DATA ,STACK. 
MEMORY) 


INPUT 
MODULES 
INCLUDED: 
: FI: 
MATRl 
Y .OBJ 
(EXECUTION 
VEHICLE 
) 
,Fl: 
FIND.oaJ 
(FINO) 
sacIOS. 
LI B (sacco) 


RESULT 
WRITTEN 
TO 
: rI: 
MATRIY 
(EXECUT 
IONVEHICf.E) 
START 
ADDRESS 
IS 
<0100H,0002H) 


01000H 
298H 
G 
/GS/ 
CGROUP 
Bl000H 
21DH 
W 
CODE 
(EXECUTIONVEHICLE) 
CODE 
0121DH 
41H 
a 
CODe (FIND) 
CODE 


0125eH 
3AH 
W 
CODe (saCCO) 
CODE 
/Ge/ 
CGROUP 
86000H 
7970H 
G 
/GS/ 
DGROUP 
80000H 
CH 
W 
CONST 
(EXECUTIONVEHICLE) 
CQNST 


8000CH 
0H 
W 
CONST (saCCO) 
CONST 


8000CH 
7921\H 
W 
DATA 
(EXECUTIONVEHICLE 
l 
DATA 
87936H 
2H 
W 
DATA 
(FIND) 
DATJI. 


87938H 
0H 
W 
DATA (saCCO) 
DATA 
87940H 
30H 
sw 
STACK 
STACK 
87970H 
0H 
W 
MEMORY 
MEMORY 


/Ge/ 
DGROUP 
87970H 
0H 
G 
??seG 
(FIND) 
(NULL) 


1-98 


The object code is then converted to hex format 
and downloaded to the iSBC 86/12 board. When 
the program is executed, the ~aximum 
value is 


calculated and output on the console. 


-SBC861 


ISIS-II 
ISBC 
86/12 
LOADER, 
1/1.2 


IS8C 
86/12 
MONITOR, 
,v!. 
2 


. LS,: 
FI: 
MATRIY. 
HEX 


.SlAC, 
F4- 
~ 
.G 
0002- 
FA 


MAX 
VALUE 
= 
+00308 


@0108:01AO 
55 


VI. CONCLUSION 


This application note has described the iSBC 957 
Intellec-iSBC 
86/12 
Interface 
and 
Execution 


Package, and how this package may be used to 
develop and debug programs for the 8086 processor. 
First, the iSBC 86/12 single board computer was 
described, followed by a detailed description of the 
iSBC 957 package and the iSBC 86/12 
system 


monitor commands. The power and versatility of 
the iSBC 957 package and monitor commands for 
developing and debugging programs for the 8086 
were illustrated 
by a program 
example. 
In the 
example a program which consisted of PL/M-86 
and assembly language routines was presented. The 
program code was explained, and the steps required 
to compile, assemble, link, locate, and debug the 
program 
were illustrated. 
Finally, a typical de- 
bugging session using the iSBC 86/12 system moni- 
tor which illustrates the powerful capabilities of the 
monitor was presented. 
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iSBCTM 86/12 
SIMPLIFIED 
LOGIC DIAGRAM 


ROM / EPROM AND DUAL PORT RAM 


APPENDIX 
B 


PROGRAM 
LISTINGS 
FOR EXECUTION$VEHICLE 
AND 
FIND MODULES 


ISIS-II 
PL/M-Bfi 
Vl.~ 
COMPILATION 
OF 
MODULE 
EXECUTIONVEHICLE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:MATRIX.OBJ 


COMPILER 
INVOKED 
BY: 
PLMBFi 
:Fl:MATRIX.PLM 
DEBUG 


® 


1. 
II 
@ 


J 2 
13l' 


15 
H 
17 
I" 
19 
20 
21 


22 


73 


@{ 


" 
25 
26 


27 
2. 
29 


PL/f'1-B6 
MAIN 
PROGRAM 
WHICH: 
A) 
INITIALIZES 
TWO 
INTEGER 
f'o1ATRICES 
B) 
MULTIPLIES 
THE 
TWO 
MATRICES 
AND 
STORES 
THE 
RESULT 
IN 
A 


THIRD 
MATRIX 
C) 
CALLS 
AN 
ASSEMBLY 
LANGUAGE 
PROCFDURE 
WHICH 
SEARCHES 
THE 
THIRD 
MATRIX 
FOR 
THE 
MAXIMUM 
V,b.LUE 
D) 
CALLS 
A 
PL/M 
PROCEDURE 
WHICH 
CONVERTS 
THE 
MAXIMUM 
VALUE 


FROM 
INTEGER 
TO 
ASCII 


E) 
CALLS 
p. 
PROCEDURE 
WHICH 
OUTPUTS 
THE 
ASCII 
CHARACTERS 
ON 


THE 
SYSTEM 
CONSOLE 


1* 
FIND$MX 
- 
EXTERNAL 
ASSEMBLY 
Ll\NGUAGE 
PROCEnURF 
WHICH 
SEP..RCtlES 
A 


MATRIX 
fOR 
THE 
LARGEST 
ABSOLUTE 
MAGNITUDE. 


PARAMETERS: 


MATRIX$I\OR 
- 
ADDRESS 
OF 
THE 
"'lATRIX 
TO 
Rr. 
SEARCHED 


ROWS 
- 
NUMBER 
Of 
ROWS 
IN 
THE 
MATRIX 
COLe; 
- 
NUMBER 
OF 
COLUMNS 
IN 
THE 
MJlTRIX 


*/ 
F'JNDSMX: 
PR(lCEDURE 
(MATRIX$PTR, 
ROWS, 
COLS) 
INTEGER 
EXTERNAL; 


DECLARE 
(ROWS, 
COLS) 
INTEGER; 


DECLARE 
MATRJXSPTR 
POINTER; 
END 
FINO$MX; 


1* 
BIN$OEC$ASC 
- 
BINARY 
TO 
DF'CJMAL 
ASCI 
[ 
CONVERSION 
PROCEDURE 
PARAME7ERS: 


VALUE 
- 
INTEGER 
V,ALUE 
TO 
BE 
CONVERTED 
TO 
ASCII 


CHP.R~ARRI\Y$ADR 
- 
ADDRESS 
OF 
6 
BYTE 
ARRAY 
WHERE 
ASCI 
I 
STRING 
CONTAINING 
TH~ 
VALUE 
WILL 
BE 
STORED 


DECLARE 
(VALUE, 
TEMP, 
I) 
INTEGER; 


DECL.l\RE 
CHAR~ARRAY$ADR 
POINTER; 


DECLARE 
(CHAR!:ARRAY 
BASED 
CHP.R$ARRAY$ADRj 
(6) 
BYTE; 


IF 
VALUE 
< 
P 
THEN 


DO; 


CHARSARRAY(~) 
'= 
,_,. 
1* 
SIGN 
CHARJlCTER 
*1 


TEMP 
'= 
-VALUE; 


END; 
ELSE 


DO; 


CHAR~ARnAY(~) 
'= 
'+'; 
TEMP 
'= 
VALUE; 


END; 
DO 
J 
'= 
5 
TO 
1 
BY 
-1; 


CHARSARRAY{I) 
'" 
UNSIGN(TEf"lP 
MOD 
10) 
+ 
3rH; 


TEMP 
'= 
TEMPI) 
"'; 


1* 
ASCII 
CHARACTERS 
::'(1 
THRU 
.19 
HEX 
REPRESENT 
THE 
DIGITS 
e 
THRU 
9. 
THUS 


TO 
CONVERT 
AN 
INTEGER 
TO 
ASCII 
REPEI>.TED 
DIVISIONS 
BY 
1(1 
AND 
ADDING 


THE 
RE/'lAINDER 
TO 
.;tr, 
HEX 
WILL 
ACCOMPLISH 
THE 
CONVERSION 
*1 
END; 


1* 
CO 
- 
EXTERNAL 
PROCEPURE 
TO 
OUTPUT 
A 
CHARACTER 
TO 
THE 
SYSTEM 
CONSOLE. 


THIS 
PROCEDURE 
IS 
PART 
OF 
THE 
JSBC 
957 
LIBRJI.RY 
FOR 
CONSOLE 
1/0 


PARAMETER: 


CHAR 
- 
ASCII 
CHARACTER 
TO 
BE 
OUTPUT 
ON 
THE 
CONSOLE 
*/ 
CO: 
PROCEDURE 
(CHAR) 
EXTERNJI.L; 


DECLARE 
CHAR 
ElYTE; 


END 
CO; 


11t 
MATRIX 
DIMENSIONS 
*1 


DECLARE 
M 
LITERALLY 
'6'; 


DECLARE 
N 
LITERALLY 
'5'; 


DECLARE 
P 
LITERALLY 
'3'; 


1* 
THE 
THREE 
MATRICES 
ARE 
DECLARED 
AS 
ARRAYS 
OF 
STRUCTURES. 
XSROW 
IS 
COMPOSED 
OF 
M STRUCTURES 
EACH 
OF 
WHICH 
IS 
COtolPOSED 
OF 
N 
INTEGER 
ELEtolENTS. 
THUS 


XSROW 
MAY 
BE 
THOUGHT 
OF 
AS 
A 
M 
X 
N 
MATRIX. 
THE 
MATRIX 
WILL 
BE 
STORED 
AS 


A 
ROW-ORDER 
MATRIX 
WITH 
THE 
ELEMENTS 
OF 
EACH 
ROW 
STORED 
IN 
ADJACENT 
MEMORY 


LOr.ATIONS. 
Y$ROW 
IS 
DECLARED 
AS 
A 
N 
X 
P 
MATRIX 
AND 
Z$ROW 
AS 
A 
N 
X 
P 
MATRIX 
*1 


DECLARE 
X$ROW(M) 
STRUCTURE 
(COL 
(N) 
INTEGER); 
DECLARE 
'{SROW(Nl 
STRUCTURE 
(COL(P) 
INTEGER); 
DECLARE 
Z$ROW(M) 
STRUCTURE 
(COLCP) 
INTEGER); 
DECLARE 
(I,J,K,MAX) 
INTEGER; 
DEC~AR' 
MAXSASCSARRAY'~ 
I 
BYTE, 
DECLARE 
TEXT C.) 
BYTE 
DATA 
('MAX 
VALUE 
'= 
'l; 


36 
37 
'" 
39 


® 


'e 


<1" 
43•• 
'5 


©{ 


.6 
'7 
'8 
'9 
5. 
51 
52 
53 
@ 
54 


® 


55 


®\ 


56 
57 
5~ 


59 
6. 
61 


62 


If, 
INITI 
..••LIZE 
XSROW 
SUCH 
THAT 
THE 
FIRST 
ROW 
IS 
SET 
EQUAL 
TO 
0, 
THE 
SECOND 
ROW 
EQUAL 
TO 
1, 
THE 
THIRD 
ROW 
EQUAL 
TO 
2, 
ETC. 
./ 
DO 
I:: 
A TO 
(M-I); 
DO J 
::: r 
TO 
(N -1) 
; 
X$ROW(I).COL{J) 
= 
Ii 


END; 


END; 


1* 
INITIALIZE 
Y$ROW 
SUCH 
THAT 
THE 
FIRST 
COLUMN 
IS 
SET 
EQUAL 
TO 
~, 
THE 


SECOND 
COLUMN 
EQUAL 
TO 
-1, 
AND 
THE 
THIRD 
COLUMN 
EQUAL 
TO 
-2. 
'*/ 
DO 
I 
= 
e 
TO 
(N-l); 


DO 
.J 
::: 
~ 
TO 
(P-l) 
i 
YSROW(I) 
.C'OL(J) 
= -J; 


END; 
END; 
/" 
PERFORM 
MJl.TR!X 
MULTIPLICATIOt-l 
*/ 
DOK=iTO(P-]); 


DO 
I 
:: 
" 
TO 
(M-I); 
Z$ROW{I).CQL(K) 
= 
eo; 
1* 
SET 
Z$ROW 
ELEMENT 
TO 
~ */ 


DO J 
::: r 
TO 
(N-l); 
1* 
SUM 
THE 
PRODU("r 
OF 
XSROW 
ROW 
TERMS 
AND 
Y$ROW 
COLUMN 
TERMS 
*/ 


Z$ROW(I).COL(K) 
= 
ZSROW(l).COL(K) 
+ 
( 
XSROW(I).COL{J) 
.• 
Y$ROW(J).COL(Kl 
); 
END; 
END; 


END; 


"'lAX 
= 
FINO$MX 
(fIZ~RO~, 
H, 
P); 
1* 
FIND 
MAX 
VALUE 
OF 
ZSROW 
"I 


CALL 
BINSOEC$ASC 
(MAX, 
(ilMAXSASC$ARRAY) 
i 
1* 
CONVERT 
'1'0 
DECIMAL 
ASCII 
"I 


DO 
I 
= 
" 
TO 
(SIGNED(SIZEtTEXT» 
- 
1); 
I" 
OUTPUT 
HEADER 
TEXT 
"I 
CALL 
CO(TEXT(I)); 


END; 


DO 
I 
= 
0 
TO 
5; 
I" 
.OUTPUT 
ASCII 
MAX 
VALUE 
"I 


CALL 
CO (MAXSASCS1IRRAY 
(I) 
l ; 


END; 


CODE 
AREA 
SIZE 


CONSTANT 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


Ml\XIMUM 
STACK 
SIZE 
137 
LINES 
READ 
£I 
PROGRAM 
F:RROR(S) 


£I225H 
A~r.CH 


O"gOH 
"'008H 


ISIS-II 
MCS-86 
ASSEMBLER 
ASSEMBLY 
OF 
MODULE 
FIND 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:FIND.OBJ 
ASSEMBLER 
INVOKED 
BY: 
ASM86 
: F 1: FIND. 
ASM 
DEBUG 


® 


FINDMX 
ASSEMBLY 
LANGUAGE 
PROCEDURE 
TO 
FIND 
THE 
ELEMENT 
OF 
AN 
INTEGER 


MATRIX 
WITH 
THE 
LARGEST 
ABSOLUTE 
MAGNITUDE. 
THE 
VALUE 
OF 
THE 
ELEMENT 
IS 
RETURNED 
IN 
THE 
AX 
REGISTER. 


PARAMETERS: 
ADR$OF$MATRIX 
- 
ADDRESS 
OF 
THE 
MATRIX 
WHICH 
WILL 
BE 
SEARCHED 


'$OF$ROWS 
- 
NUMBER 
OF 
ROWS 
IN 
THE 
MATRIX 
,$OF$COLS 
- 
NUMBER 
OF 
COLUMNS 
IN 
THE 
MATRIX 


PL/M 
WILL 
PASS 
THE 
THREE 
PARAMETERS 
IN 
THE 
CALL 
TO 
THIS 
PROCEDURE 
ON 
THE 
STACK. 
ON 
ENTRY 
TO 
THE 
PROCEDURE 
SP+6 
WILL 
POINT 
TO 
THE 
FIRST 


PARAMETER 
(ADR$OF$MATRIX) 
AND 
SP+4 
AND 
SP+2 
WILL 
POINT 
TO 
THE 
SECOND 


AND 
THIRD 
PARAMETERS. 


THE 
PROCEDURE 
IS 
A 
TYPED 
PROCEDURE 
WHICH 
ASSIGNS 
THE 
MAXIMUM 
VALUE 


IN 
THE 
MATRIX 
TO 
A 
VARIABLE 
(IN 
THIS 
CASE 
MAX$VALUE) 
IN 
A 
PLIM 


ASSIGNMENT 
STATEMENT. 
TO 
ACCOMPLISH 
THIS 
ASSIGNMENT 
THE 
VALUE 
IS 
RETURNED 
IN 
THE 
AX 
REGISTER. 


THE 
ALGORITHM 
USED 
IS 
SIMILAR 
TO 
THE 
FOLLOWING 
PLIM 
CODE: 
FOR 
I 
= 
9 
TO 
<'$OF$ROWS 
- 
1); 
FOR 
J 
•• 
TO 
C'SOFSCOLS 
- 
1); 
IF 
IABS(MATRIX(I).Y(J)) 
> 
IABS(MAXl 
THEN 
MAX 
= 
MATRIX(I).Y(J); 


END; 


END; 


LOC 
OBJ 
0{ 
0{ 
~HHHI "''''''' 
®{ 


000P 
(.14 
~~"''' 
) 


00'- 
I] 
"""4 r ] 
0008 I J 
"P'''~ 
~~00 
55 
Pl001 
8BEe 
0"pI) 
3302 
""05 
BSFA 
0007 
BBF2 
~H:'09 
89160000 
0000 
884E04 
0010 
OIE1 


'HI 1 2 
PB5E90a 


CD 


(HH5 
8800 
'lei? 
0BC0 
iii" 19 
7902 


~01B 
F7DB 
'HED 
38C7 


e-0] 
F 
7C07 
~~21 
8BD~ 
0023 
BRae 
rr25 
A300ee 
0028 
83C602 
0"'28 
3BFl 
0020 
72EI) 
J"2F 
8018 
11'031 
BEIHHH" 
~031! 
47 
""ns 
387£06 
0038 
7208 


01DA 
A10000 
0030 
50 


003E 
C20600 


DEFINE 
GROUPS 
TO 
CONFORM 
WITH 
PL/M-86 
CONVENTIONS. 
DATA, 
STACK, 
AND 


CODE 
SEGMENTS 
WILL 
BE 
APPENDED 
TO 
THEIR 
RESPECTIVE 
SEGMENTS 
IN 
THE 


PL/M-86 
MODULES. 
GROUP 
DATA, 
STACK 


GROUP 
CODE 


INSTRUCT 
THE 
ASSEMBLER 
THAT 
'rHE 
os, 
55, 
AND 
CS 
REGISTERS 
WILL 
CONTAIN 


THE 
BASE 
ADDRESS 
VALUES 
FOR 
THE 
DGROUP, 
DGROUP 
AND 
CGROUP 
GROUPS. 


ASSUME 
OS: IX>ROUP, 
55: 
DGROUP 
I CS: CGROUP 


DATA 
SEGMENT 
WORD 
PUBLIC 
I DATA 
I 
MAX 
DW 
121 
DATl\ 
ENDS 


; PARAMETERS 
ON 
NO 
OF 
ROWS 
No-oF-CoLS 
AO'R"_ot"_MATRIX 


FINDMX 
PRoC 
PUSH 
MOV 
XOR 
MOV 
MOV 
MOV 
MOV 
SHL 


; 
FINDMX 
ENDP 


CODE 
ENDS 


SYMBOL 
TABLE 
LISTING 


NAME 
TYPE 
VALUE 
ATTRIBUTES 


??SEG 
SEGMENT 
SIZE=0e00H 


ABC 
L 
NEAR 
Pl01SH 
CODE 


ADR 
OF 
MATRIX 
V 
WORD 
0008H 
IBP) 
CGROUP-:- 
GROUP 
CODE 


CODE. 
SEGMENT 
SIZE=0041H 


DATA. 
SEGMENT 
SIZE=0002H 


OEF 
L 
NEAR 
Pl01DH 
CODE 


DGROUP. 
GROUP 
DATA 
STACK 


FINDMX. 
L 
NEAR 
ee00H 
CODE 
PUBLIC 
!'lAX 
V 
WORD 
0000H 
DATA 
NO 
OF 
COLS. 
V 
WORD 
121 121 04H 
IBP) 


No-OF-ROI,<IS. 
V 
WORD 
{HH"6H 
IBP) 


STACK- 
SEGMENT 
SIZE=C'l01CH 


XYZ 
L 
NEAR 
0028H 
CODE 


ASSEMBLY 
COMPLETE, 
NO 
ERRORS 
FOUND 


STACK, 
DISPLACEMENT 
FROM 
TOS 
INCREASED 
BY 
TWO 
DUE 
TO 
INITIAL 
PUSH 


EQU 
WORD 
PTR 
[BP+6J 
EQU 
WORD 
PTR 
[BP+4] 
EQU 
WORD 
PTR 
[BP+8j 


iTERMINATION 
FOR 
J (51) 
INDEX 


BX,ADR_oF_MATRIX 
iADR$OF$MATRIX 
PARAMETER 


ex 
POINTS 
TO 
FIRST 
ELEMENT 
OF 
A 
GIVEN 
ROW 


GET 
ELEMENT 
OF 
MATRIX 
SET 
FLAGS 
JUMP 
IF 
SIGN 
= 
0 
NEGATE 
TO 
FORM 
POSITIVE 
NUMBER 
COMPARE 
TO 
CURRENT 
MAX 


JUMP 
IF 
LESS 
THAN 
CURRENT 
MAX 


MOVE 
TO 
ABS 
OF 
CURRENT 
MAX 


MOVE 
MATRIX 
V"'LUE 
TO 
CURREN'}' 
MAX 


NE"'R 
BP 
BP,SP 


OX,OX 
DI,OX 
SI,OX 
MAX,DX 
CX ,NO 
OF 
COLS 


Cx,l 
- 


AX, 
[BX] 
ISI) 


AX,AX 
OEF 


AX 
AX,OX 
XY2 
nx,"'x 
AX, 
[BX] 
ISI) 
MAX ,AX 
SI,2 
SI,CX 
ABC 


BX, 
rBX+Slj 
SI,12I 
01 


DI,NO 
OF 
HOWS 


ABC 
AX,MAX 
BP 
6 


iPROCEDURE 
OECL"'RATION 
iSAVE 
BP 
REGISTER 


i BP 
POINTS 
TO 
PARAMETERS 
ON 
STACK 
i SET 
OX = 
ASS 
OF 
CURRENT 
MAX 
= 
0 


;01 
= 
I 
(ROW 
INDEX) 
= 
0 


iSI 
= 
J (COLUMN 
INDEX) 
= 
0 


i MAX 
= 
CURRENT 
MAX 
= 
0 


INCREMENT 
J 
INDEX 
BY 
TWO 


END 
OF 
THIS 
ROW?? 
IF 
NO, 
LOOP 
BACK 
FOR 
NEXT 
ELEMENT 
OF 
THIS 
ROW 


BX 
= 
BX 
+ 
(2 
• 
t$OF$COLS), 
BX 
POINTS 
TO 
NEXT 
ROW 


J 
= 
" 
I 
= 
J 
+ 1 
L"'ST 
ROW 
?? 


IF 
NO, 
DO 
THE 
NEXT 
ROW 
RETURN 
MAX 
VALUE 
IN 
AX 
REG ISTER 


RESTORE 
BP 
REGISTER 
INCREMENT 
SP 
BY 
6 
"'NO 
RETURN 
TO 
C"'LLER 


INPUT 
MonULES 
INCLUDED: 
: PI 
: MATRIX. 
ORJ 
(F:XE'CUrrONVEIHCLF.: 
l 


: F 1: FIND.OBJ 
(FIND) 
SBCIOS. 
LIB 
(S8CCO,\ 


@ 


STAR'r 
LTH 
ALIGN 
NAME 
CLASS 


~100PH 
7AIlH 
G 
/GS/ 
CGROUP 


PI "e0H 
725H 
'. 


CODE 
(EXECUT 
IONVEHICLE) 
CODE 


91225H 
, 1H 
B 
CODE 
(FIND) 
CODE 


1?'12~GH 
JAH 
W 
CODE 
(SBCCO) 
CODE 


/GE/ 
CGROUP 


"12M'H 
DOH 
G 
/GS/ 
DGROUP 


e12",0H 
CH 
w 
CONST 
(EXt:CUTIONVEHICLE) 
CONST 


1"12ACH 
OH 
W 
CaNST 
(SPCCO) 
CaNST 


012ACH 
9.H 
W 
DATA 
(EXECUTIONVEHICLE) 
DATA 
913 
3CH 
2H 
•. 
DATA(FIND) 
DATA 


013.':IEH 
0H 
W 
DATA 
(saCCO) 
DATA 


9134P1H 
?0H 
SW 
STACK 
STACK 


fl1370H 
0H 
W 
MEMORY 
MEMORY 


/GE/ 
DGROUP 
p 
370H 
OH 
G 
??SEG 
(FIND) 
(NULL) 


DEBUG 
MAP 
OF 
: F1: 
MATR IX (EXECUTIONVEIIICLE) 


MODULE: 
EXECUTJONVEHICLE 
el~0H,01E1H 
LINE ., 
19 
rH'eH,e13~H 
LINE " 


52 


012AH, 
e0DBH 
SYMBOL 
MEMORY 
p.l~eH, 
"'lFSH 
LINE ., 
2. 
01BPlH,r.l42H 
LINE 
" 
53 


PJI0~H,r·lBSH 
SYMBOL 
BINDECASC 
PllPl"H 
,Pl21:H 
LINE .' 


21 
0JPI,m,~1"PH 
LINE .' 


5' 
1?'12AH,PJe~CH 
SYMBOL 
TEMP 
I?'lPJ~H,r21EH 
LINE .' 


22 
01~0H, 
rISEH 
LINE 
• 
55 
AI2AH, 
P0p1EH 
SYMBOL 
I 
010~H,022IH 
LINE " 


23 
r;ll::leH,~] 
r.9H 
LINE 
! 
5' 
P'DAH, 
~010H 
SYMBOL 
XROl,or 
0U0H,Ce02H 
LINE 
" 
3' 
01e0H,0I7AH 
LINE 
I 
57 
r;12AH,17l04CH 
SYMAOL 
YROW 
I"Jlil0H,0~21H 
LINE " 


37 
r10€H,lU65H 
LINE 
• '" 
~12AH,e"'6AH 
SYMBCL 
ZROW 
(1I0~H,e17l32H 
LINE .' 


38 
"10eH, 
AISEH 
LINE 
I 
<9 


® 


A17AH,0PJ8EH 
SYMBOL 
I 
P.llH'H,AB4BH 
LINE .' 


19 
OJ10BH,rJ9FH 
LINE 
• 
6" 
e12,.,H, 
"'''9Il1H 
SYMBOL 
J 
"1~0H,AA5I1H 
LINE " '. 


010eH, 
~ lAAH 
LINE , 
61 
r.] 2AH, 
P1r'92H 
SYMBOL 
K 
P'l9'~H, 
005DH 
LINE .' 'I 
(':HH'H, 
P 113 3H 
LINE , "' 
P"l2AH, 
r094H 
SYMBOL 
MAX 
r l Vl"H, 
p'ef;EH 
LINE " 


"2 
MODULE 
FIN 


171I2AH,A~9I\H 
SYMBOL 
MAXASCARRAY 
01"'~H,0P7FH 
LINE 
I 
'3 
0100H,023AH 
SYMBOL 
ABC 


Pl12AH,r000H 
SYMBOL 
TEXT 
ll'l~I"H, 
009CH 
LINE , " 
0100H, 
e242H 
SYMBOL 
DEF 


0IPl~H,PIB5H 
LINE 
I 
6 
01P0H,0P1ASH 
LINE , 
'5 
0100H,'J225H 
SYMBOL 
FINDMX 
P100H,l?'lB8H 
LINE 
1. 
0] 
00H, 
f'0AEH 
LINE • 
" 


012AH,009CH 
SYMBOL 
MAX 


P1HII?'H,01C2H 
LINE 
12 
P1Ie0H,0eBFH 
LINE • 


<7 
0le0H,024DH 
SYMBOL 
XY2 
A10P.H,P1ICBH 
LINE 
13 
B 1 e0H, 
00DPH 
LINE • '. 


0UeH,0225H 
PUBLIC 
FINDf"IX 
0HH'H, 
elDlH 
LINE 
14 
rl"~H,I?'AE7H 
LINE • 
49 
MODULE 
sacco 
l!I100H,"lD~H 
LTNE 
10 
0100H,00F8H 
LINE 
• 
5P 
el00H,0266H 
PUBLIC 
CO 


P110P'H,01DAH 
LINE 
17 
P1H"0H,0J3V,H 
LINE 
• 


51 


ISIS-II 
PL/M-Et~ 
V1.e 
COMPILATION 
OF 
MODULE 
EXECUTIONVEHICLE 
NO 
OBJECT 
MODULE 
REQUESTED 


COMPILER 
INVOKED 
BY: 
PLM8fl 
:Fl 
:MATRIX.PLM 
DEBUG 
CODE 
NOOBJECT 
PRINT(:Fl:MATRIX.XLS) 


PL/M-36 
MAIN 
PROGRAM 
WHICH: 


1\) 
INITIALIZES 
TWO 
INTEGER 
MATRICES 


B) 
MULTIPLIES 
THE 
TWO 
M,ll,TRICES 
AND 
STORES 
THE 
RESULT 
IN 
A 
THIRD 
MATRIX 
C) 
CALLS 
AN 
ASSE"lBLY 
LANGUAGE 
PROCEDURE 
WHICH 
SEARCHES 
THE 


THIRD 
MATRI 
X 
FOR 
THE 
MAXIMUM 
VALUE 
D) 
CALLS 
A 
PL/M 
PROCEDURE 
WHICH 
CONVERTS 
THE 
"lAXIMUM 
VALUE 
FROM 
INTEGER 
TO 
ASCT r 
E) 
CALLS 
A 
PROCEDURE 
WHICH 
OUTPUTS 
THE 
ASCII 
CHARACTERS 
ON 
THE 
SYSTEM 
CONSOLE 


/.. 
FTND$J'1X 
- 
EXTERNAL 
ASSEMBLY 
LANCUAGE 
PROCEDURF: 
WHICH 
SEARCHES 
A 
MATRIX 
FOR 
THE 
LARGEST 
ABSOLUTE 
MAGNITUDE. 
PARAMETERS: 
MATRIX$ADR 
- 
l\ODRESS 
OF 
THE 
MATRIX 
TO 
BE 
SEARCHED 
RailS 
- 
NUMBER 
OF 
ROWS 
IN 
THE 
MATRIX 
COLS 
- 
NUMBER 
OF 
COLUMNS 
IN 
THE 
MATRIX 
'j 


FINO$MX: 
PROCEDURE 
(MATRIX$PTR, 
ROWS, 
COL~) 
INTEGER 
EXTERNAL; 


DECLARE 
(ROWS, 
COLS) 
INTEGER; 


DECLARE 
MATRIXSPTR 
POINTER; 


END 
FINO$MX; 


/", 
BIN$DECSASC 
- 
BINARY 
TO 
DECIMAL 
A~CII 
CONVERSION 
PHOCEDURE 


PAI1AMF-:TERS: 


V,ll.LUE 
- 
INTEGER 
VALUE 
TO 
BE 
CONVERTED 
TO 
ASCI! 
CHAR$ARRAY$ADR 
- 
ADDRESS 
OF 
Ii 
BYTE 
ARRAY 
WHERE 
ASCI 
I 
STRING 
CONTAINING 
THE 
VALUE 
WILL 
BE 
STORED 
* j 
BJNSDECSASC: 
PROCEDURE 
(V".LUE, 
CHARSARRAY$ADR); 
; 
STATEMENT 
II: S 
BINDECASC 
PUSH 
MOV 


PROC 
NEAR 
BP 
BP, 
SP 


DECLARE 
(VALUE, 
TEMP, 
I) 
INTEGER; 


DECLARE 
CHAR$ARRAY$ADR 
POINTER; 


DECLARE 
(CHARS".RRJlY 
BASED 
CHAR$ARRAY$ADR) 
Pi) 
BYTE; 


IF 
VALUE 
< 
Ii' 
THEN 


01BR 
817E0fl0000 
CMP 


P IBD 
7C03 
JL 


B1BF 
E912~~ 
JMP 
DO; 
CHARS,ll.RRAY(0) 
'-'. 


; 
STATEMENT 
~ 
10 
rBP].VALUE,0H 


S+5H 
@! 


~lC2 
8B5E~4 
MOV 
01C5 
C60770 
MOV 
TEMP 
= 
-VALUE; 


/*' 
SIGN 
CHAR,A.CTER 
*'/ 


; 
STATEMENT 
, 
] 2 


BX, 
rBPj.CHARARRAYADR 


CHAR1\RRAY 
fBX} 
,2DH 


01CA 
8B41506 
01CB 
F7D8 
(' leD 
89~6P'0C'0 


END; 


; 
STATEMENT 
13 
AX, 
fBP]. 
VALUE 
AX 
TEMP,AX 


ELSE 
DO; 
CHAR$ARRA 
Y (P) 


01D4 
8B5E~4 
0107 
C6077B 


TEMP 
= 
VALUE; 


; 
STATEMENT 
• 
liS 


ax, 
fBP] 
.CHARARRAYADR 
CHARARRAY 
r ax 1, 2BH 


Pol0" 
8840;06 


0100 
89nliPP0A 


END; 


; 
STATEMENT 
17 
AX, 
(BP]. 
VALUE 
TEMP,AX 


rIEl 
C70602000500 
elE7 
E~P6r0 
@3, 


13]EA 
8U~6e2e'AFFFF 


~5 , 


e:13E~7e0~1f'0 
70e3 
E926VP 


CHARSARRAY(I) 


8BPf)0000 
890APlE! 
3102 
F7F9 
R]C;?3e0~ 
885£04 
8B3602~0 
881P 
TEMP'" 
TEMP/JA; 


eMP 
I, 
IH 


JGE 
$+5H 


J!llP 
fl4 


UNSIGN(TEMP 
MOD 10) 
+ 
3PH; 
; 
STA.TEMENT 


MOV 
MV 
xaR 
IDlV 
Aaa 
"av 
Mav 
Mav 


AX, TEMP 
ex, eAA 
DX,OX 
cx 
DX, 
3~1I 


ax, 
[BP1.CHARARRAYADR 
51,1 
rex] 
• CHARARRAY 
rSI 
J I DL 


; 
STATEMENT 
, 
21 


/* 
A.Bell 
CHARACTERS 
313 TARU 
39 
HEX 
REPRESENT 
THE 
DIGITS 
~ 
THRU 
9. 
THUS 


TO 
CONVERT 
AN 
INTEGER 
TO 
ASCII 
REPEATED 
DIVISIONS 
BY 
lP. 
AND 
ADDING 


THE 
REMAINDER 
TO 
3e 
HEX 
WILL 
ACCOMPLISH 
THE 
CONVERSION 
*/ 
r213 
8SPlf)pe90 
MOV 
AX,TEMP 


0217 
99 
CWO 


0218 
F7F9 
IDIV 
ex 


02IA 
890600A0 
MOV 
TEMP,AX 


END; 


0221 
SO 
POP 
SP 


022? 
C2P!4A/'l 
RET 
dA 
B IND£CASC 
ENDP 


1* 
co - 
EXTERNAL 
PROCEDURE 
TO 
OUTPUT 
p.. 
CHARACTER 
TO 
THE 
SYSTEM 
CONSOLE. 
THIS 
PROCEDURE 
IS 
PART 
OF 
THE 
Isac 
~57 
LIBRARY 
FOR 
CONSOLE 
I/O 
PARAMETER: 


CHAR 
- 
ASCII 
CHARACTE:R 
TO 
BE 
OUTPUT 
ON 
THE 
CONSOLE 


*/ 
ro: 
PROeF:DURE 
(CHAR) 
EXTERNi\L; 


DECLARE 
CHAR 
BYTE; 


END 
CO; 


1ft 
MATRIX 
DIMENSIONS 
ft I 
DECLARE'" 
LTTE:RALLY 
'6'; 


DECLARE 
N 
LITERALLY'S'; 


DECLARE 
P 
LITE:RALLY 
'3'; 


1 


ft 
THE 
THREE 
MATRICES 
ARE 
DECLARED 
AS 
ARRAYS 
OF 
STRUCTURES. 
X$ROW 
IS 
COMPOSED 
OF 
M STRUCTURES 
EACH 
OF 
WHIC!-I 
IS 
COMPOSED 
OF 
N 
INTEGER 
ELEMENTS. 
THUS 
X$RCM 
MAY 
RE 
THOUGHT 
OF 
AS 
A 
M 
X 
N 
MATRIX. 
THE 
MATRIX 
WILL 
BE 
STORED 
AS 
A 
ROW-ORDER 
MATRI 
X 
WITH 
THE 
ELEMENTS 
OF 
EACH 
ROW STORED 
IN 
ADJACENT 
MEMORY 


LOCATIONS. 
Y$ROW 
IS 
OECLARED 
AS 
A 
N 
X 
P 
MATRIX 
AND 
Z$ROW 
AS 
A 
N 
X 
P 
MATRIX 
ftl 
DECLARE 
X$ROW{M) 
STRurTURE 
(COL (N) 
INTEGER); 


DECLARE 
Y$ROW(N) 
STRUCTURE 
(COL(P) 
INTEGER); 


DECLARE 
Z$ROW{M) 
STRUCTURE 
(eOL 
(P) 
INTEGER); 


DECLARE 
(I,.l,K,MAX) 
INTEGER; 


DECL/lRE 
MAX$ASC$ARRAY 
(,:j) 
BYTE; 
DECLARE 
TEXTtft) 
eyrE 
nATA 
(''''AX 
VALUE 
= 
'); 


1ft 
INITIALIZE 
X$ROW 
SUCH 
THAT 
THE 
FIRST 
ROW IS 
SET 
EQUAL 
TO 
PI, 
THE 
SECOND 
ROW EOUAL 
TO 
1. 
THE 
THIRD 
RO\V' EQUAL 
TO 
2, 
ETC. 
ftl 
DO 
I 
= 
0 
TO 
(M-); 


~P1B2 
FA 
CLl 
00B3 
2E8F.160~P" 
Mav 
SS, CS:@@STACK$FRAME 
{HteB 
BCABe0 
Mav 
SP ,@~STACK$OFFSET 
A008 
8BEC 
Mav 
BP, SP 


0000 
16 
PUSH 
SS 
gA0E 
IF 
POP 
OS 


"BBF 
FB 
STI 
BBHt 
C70682B~H"000 
"av 
I, 
~H 


~6, 
Ae16 
8I3E820e~50A 
C"P 
1,5H 


"Ale 
7EP3 
~1LE 
$+sH 


POlE 
E93C,,"" 
J"P 
~7 
17 
aa 
J 
: 
o 
TO 
(N-1) 
; 


STATEMENT 
I 37 


0"/.1 
C7e68400A00C 
Mav 
J,0H 


~8 , 


(llfl27 
e13EB40~04PP 
CMP 
.1,4H 
BA2D 
7EP3 
.1LE 
S+5H 
002F 
E9220'-" 
JMP 
@9 
38 
XSROW (I) 
.eOL 
(J) .I; 


5Ti\TEMF.NT 
I 
3B 
"0J2 
J;JB0fi82P0 
Mav 
AX,l 
~"3fi 
89VACH" 
Mav 
CX, 
~AH 


IHJ39 
F7E9 
IMUL 
cx 
{HOB 
8B36840V 
Mav 
SI ••1 


0A3F 
01E6 
SI-lL 
SI,l 
0041 
Age3 
Mav 
ex,AX 
0043 
8B~E82~e 
Mav 
CX, 
I 


VAIl7 
898804"" 
Mav 
(ex J. XRQW rSI 
1 ,CX 


39 
END; 


1·108 
AFN-01931A 


STATEMENT 
! 39 
P"~B 
P.1~~A4PP010e 
ADD 
J, 
1 H 
IlJClS1 
E~D3FF 
JMP 
PR 
@!?: 


'0 
END; 


; 
STATEMENT , '0 


",r.5" 
RH'fi82Poe01PO 
ADD 
I,] 
H 
r.~5A 
E9B9FF 
JMP 
PO 


i!J7 : 


r' 
INITIALJZE 
YSRC1l'l 
SUCH 
THAT 
THE 
FIRST 
COLUMN 
IS 
SET 
EQUAL 
TO 
£, 
THE 


SECOND 
COLUMN 
EQUAL 
TO 
-1, 
AND 
THE 
THIRD 
COLU/'lN 
EQUAL 
TO 
-2. 
./ 


DO 
I 
= e 
TO 
tN-I); 


0050 
C70682A00ee0 
Mev 
J,0H 
@lP: 


Iillll63 
813E8201'1~4I'1P 
CMP 
I,4H 


0e69 
7E03 
JLE 
$+5H 


9r.t'ie 
E94900 
JMP 
'J 1 
42 
De 
J 
= 
0 
TO 
(P-I) 
; 


STATEMENT 
I 
42 
O~6E 
C706849900PA 
Mev 
J, 
PH 


@12; 


01'17" 
813£84000200 
CMP 
J,2H 


"971'1 
7E03 
JLE 
$+5H 


0e7C 
£9260'" 
JMP 
@13 
'3 
Y$ROW 
(I) 
• eOL 
(J) . -J; 


STATEMENT 
f 
43 
007F 
881'168400 
Mev 
AX,J 
0083 
F7D8 
NEG 
AX 


1'1085 
5. 
PUSH 
AX 
; 
J 
0086 
88068200 
Mev 
AX, 
I 
008A 
890600 
Mev 
eX,6H 
008D 
F7E9 
IMUL 
CX 


0eSF 
88368400 
Mev 
SI,J 


0093 
DIE':; 
SHL 
81,1 


~095 
89C3 
Mev 
eX,AX 
01397 
59 
pep 
CX 
1 
P~98 
89884000 
Mav 
r8Xl.YROWf5I],eX 
" 
END; 


; 
STATEMENT 
! 
44 
91l19C 
819684P0e'1P€, 
ADe 
J,lH 
091'12 
E9CFFF 
JMP 
@l] 


.13; 
45 
E~O; 
STATEMENT 
I 
45 


0PA5 
811'1682"'0el0(' 
ADD 
I,lH 


001'18 
E9B 
srF 
JMP 
01" 
@l}: 


/' 
PERFORM 
MATRIX 
MULT:l:PUC:ATJON 
'/ 
4(, 
De 
K 
: 
• 
Te 
(P-11; 


rPAE 
C701;81\B00P011' 
Mav 
PH: 


I7nB4 
e 13ER60P0200 
CM? 


"~8A 
7E"3 
JLE 


epec 
EgeC('{l 
JMP 


DO 
[ .° 


TO 
(M-]) 
; 


0t"8F" 
C706e::eerp£l1' 
,"lOV 
n6: 


(,l.'lC5 
e I 3EBJ'HH"SIlJC' 
CfoIlP 
~,,·ce 
7E03 
JLE:: 


1'10CO 
ES'72rl" 
JMP 
'8 
ZSROW(I) 
.COL(K) 
= ,; 


(JPOl1l 
PBe~8;:W0 
Mev 


r.004 
891ll6Pr. 
Mav 


"''''D7 
F7E9 
JMUL 


1"009 
883686910 
Mav 
,"POD 
DIE" 
5HL 


OlloF 
A9C1 
Mav 
P0El 
C78P5E0PP0IH" 
Mav 


49 
oa 
J 
= 
~ 
TO 
(N-l) ; j' 


"~E7 
C7eI}840P;'HHl~ 
MOV 


@l 8: 


peED 
813Eall~PI'l4P'e 
CMP 
1'10F~ 
7E03 
JLE 
0~FS 
E~"] 
oo 
JMP 


5. 
ZSROW(I).eOL(K} 
= 


"BF8 
B8068200 
Mav 
~0FC 
89"'APr, 
Mev 
BaFF 
F7E9 
IMUL 
0101 
88368400 
Mev 
011'5 
01E6 
SHL 
1'1107 
50 
PUSH 
01~8 
88068400 
Mav 
01BC 
f\9060e 
Mav 
9JleF 
F7E9 
IMUL 
0111 
883E86PlP. 
Mav 
0115 
01 E7 
SHL 
0117 
89C3 
MoV 
0119 
8881<1000 
Mev 


0llo 
56 
pap 


011E 
F7A801!00 
IMUL 


0122 
5. 
PUSH 


0123 
oe068200 
Mav 
P127 
F7E9 
IMUL 


0129 
89C3 
Mav 


I,5H 
:;+5fl 
@l7 
/* 
SET 
Z£:R0W 
F.:LE!'1ENT TO r "'/ 
; 
5TAT!:":MENT 
6 
48 
AX, r 
CX, 
~H 


CX 
SI, 
K 


S1,1 


BX,AX 
rex) 
.ZRO\oHSI} 
,rli 


SUM 
THE 
PRODUCT 
OF 
XSRO'.II/ 
ROIo' 
TEH~S 
AND 
Y$ROW 
COLUMN 
TER"'S 
./ 


; 
STATEMENT 
I 
tJ 9 


J ,1H 
S+5H 
@19 
ZSROW(I).COL(K) 
+ 
( 
X~ROW(1).COL(J) 
• 
YSROW(J).COL(J<) 
); 


; 
5TATE,"lENT 
I 
50 
AX, 
I 
ex, rAH 
CX 
SI,J 
51,1 
AX 
; 
1 
AX,J 
ex,6H 
ex 
oI,K 
01,1 
ex, AX 


Ax,rBX1.YROW~DIl 
ex 
; 
1 
rax] 
.XROWrSI] 
AX 
; 
1 
AX, r 
CX 
8X,AX 


P12B 
~8 
POP 
AX 
I 
A12C 
e'l815EP'fl 
ADD 
faX]. 
ZROW[DI 
1 ,AX 
~1 
END; 


; 
STATEMENT 
I 51 
A130 
81068011"""100 
ADD 
J,lH 


013") 
E9B~FF 
JMP 
eJ8 
~l 9: 


52 
END; 


STATEMENT 
I 52 
0139 
81 ~")P2D"'0100 
ADD 
J,lH 


A13F 
E983FF 
JMP 
el' 
(il17: 


53 
END; 


STATEMENT 
/, 
53 


11142 
81068n'!P!l:ner, 
ADD 
!<,lH 


P.l<1~ 
E9")9FF 
JMP 
:"14 
flJ 5: 


5' 
MAX 
: 
FINDSMX 
(@Z~ROW, 
M. 
PI; 
/* 
FIND 
MAX 
VALUE 
OF 
Z$RQW */ 


; 
STATEMENT 
I 5' 


P1l4B 
885E9p1 
Mev 
AX, OFFSET 
(ZROW) 


P14E 
5~ 
PUSH 
AX 
J 


~] dF 
B8~"~V' 
"OV 
AX, 
~H 


P152 
50 
PUSH 
AX 
; 2 
0153 
BBV'3~H~ 
MOV 
AX,3H 


A] 5~ 
50 
PUSH 
AX 
; 
) 


A1S7 
E8eepr 
CALL 
FINDMX 
015A 
89A688lHJ 
MOV 
"tAX, AX 
55 
C.ALL 
BIN$DEC$ASC 
(MAX, 
FiMAX$ASC$.ARRAY) 
; 
1* 
CONVERT 
'fO 
DECIMAL 
ASCII 
*/ 


; 
STATEMENT 
I 55 
015E 
FF3fi8B0e 
PUSH 
"AX 
1 
9162 
B8BA~0 
MOV 
AX, OFFSET 
(MAXASCARRAY) 
~IG5 
50 
PUSH 
AX 
2 
9166 
E84C091 
CALL 
BINDECASC 


5C> 
DO I 
: 
~ 
TO 
(SICNEDISIZE(TEXT) 
) - 1); 
/' 
OUTPUT 
HEADER 
TEXT 
*/ 


; 
STATEMENT 
I 56 
~1~9 
C70682~HHHHHIj 
MOV 
I, 
SH 


@20' 


A16F 
P 13E820e0se0 
CMP 
I,0BH 
0] 75 
7EA3 
JLE 
$+5H 
0177 
E9141H'l 
JMP 
@2J 
57 
CALL 
co (TEXT 
(I) 
) ; 
STATEMENT 
I 57 


e17A 
BBIE8290 
MOV 
BX, I 


017E 
FFB70~00 
PUSH 
TEXT rBX} 
; 
J 


e-182 
E80""''' 
CALL 
CO 
58 
END; 


STATEMENT 
I 58 
A]85 
8]P;6(l2(\Ael~0 
ADD 
I,lH 


1l18B 
E9E]FF 
JMP 
@20 
@21 : 


59 
DO I 
: 
e 
TO 
5; 
/* 
OUTPUT 
ASCII 
MAX 
VALUE 
*/ 


; 
STATEMENT 
I 59 
C706A2"'HHHl!0 
MOV 
l,rH 
f322: 


813E82000500 
CMP 
r, 
5H 
7EP!3 
JLE 
$+5H 


E9] .HH" 
JMP 
@23 
CALL 
COlMAX$A.SCSARRAYtI)); 


019F 
8BIEA'fl~ 
"lA3 
FFB78A9I0 
PIA7 
E80000 
END; 


elAA 
8HH182e00}0P 
PIB0 
E9EIFF 


BX, 
I 


MAXASCARRAY 
r8X}; 
1 


CO 


CODE 
AREA. 
SIZE 
••• 0225H 
5490 


CONSTANT 
AREA 
SIZE 
0A0CH 
12D 


VARIABLE 
A.REA. SIZE'" 
00908 
144D 


MAXIMUM 
STACK 
SIZE"" 
0008H 
80 
137 
LINES 
READ 


o 
PROGRAM 
ERROR (5) 


END 
OF 
PL/M-86 
COMPILATION 
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As the microcomputer 
system found its way into 
more and more demanding 
applications 
the need 
became clear for a new and innovative 
solution to 


the old problem of providing 
timely response 
to 
real world events. 
This need was never clearer 


than 
in the 
field 
of communications 
where 
throughput 
and 
response 
time are the keys to 
success. The iSBC 544 Intelligent 
Communica- 
tions Controller (ICC) is the vanguard 
of a family 


of intelligent 
slave 
computers 
that 
provide 
a 
unique 
and powerful answer 
to the needs of the 


microcomputer 
user. 


This application 
note is intended to introduce the 


reader to the intelligent 
slave concept in general 


and the iSBC 544 board 
in particular. 
After a 


brief overview of the evolution of the concept and 
the 
features 
it provides, 
the 
hardware 
and 


software 
aspects 
of the controller 
are studied. 
Following 
this 
a summary 
of various 
system 


throughput 
tests 
is examined 
to evaluate 
the 
performance 
of the intelligent 
slave versus more 


traditional 
system 
architectures. 
We then study 


two example 
applications 
of the 
product 
and 


relate 
the earlier 
discussions 
to the real world. 


Finally, 
some system 
software is presented 
that 


handles 
all data transfer 
duties between master 


single board computers and intelligent 
slaves on 


the 
MULTIBUS 
system 
bus. 
More 
detailed 
information 
on many of the topics covered in this 
note can be found 
in the related 
publications 
listed in the front-piece. 


II. OVERVIEW 


Intelligent 
Slave 
Architecture 


Over 
the 
years, 
component 
technology 
has 


increased 
at a rapid 
pace going from discrete 


components 
(eg. transistors) 
to integrated 
circuits 


(eg. TTL devices) 
to programmable 
peripheral 


controllers 
(eg. Intel 8251A Universal 
Synchro- 


nous/ Asynchronous 
Receiver/Transmitter) 
to 


fully intelligent 
slave 
devices 
(eg. Intel 
8041A 


Universal 
Peripheral 
Interface). 
At the system 


level the evolution followed a similar path using 
the increasing 
component 
technology 
to create 


more and more powerful system building blocks. 
The iSBC 508 I/O board used TTL logic to provide 
digital 
I/O 
expansion 
for iSBC computers. 
The 


iSBC 534 board took advantage 
of programmable 


LSI devices to provide a programmable 
commu- 
nications 
expansion 
board. 
Now, with the advent 


of the 
iSBC 
544 Intelligent 
Communications 


Controller, 
a new level of system 
capability 
is 


made 
possible 
with 
the fully intelligent 
slave 


controller. 


The cornerstone 
of the intelligent 
slave architec- 


ture is the dual port memory. 
Through the use of 


this 
shared 
memory space, a fast and efficient 


protocol can be established 
to allow for coopera- 


tion 
between 
master 
and 
intelligent 
slave 
in 


solving 
the needs of the application 
system. 
In 


addition 
to the shared 
memory, the CPU on the 


intelligent 
slave also has 
some local RAM and 


local PROM storage for programs. 
By using this 


architecture 
the advantages 
of multiprocessing 


and Direct Memory Access (DMA) controllers 
are 


blended 
together. 
Unlike 
DMA controllers, 
the 


intelligent 
slave works totally within its own data 


space. Therefore, it is not affected by bus traffic 
nor does it add to this traffic. 
And, since the on- 


board CPU gets its instructions 
from local PROM 


instead 
of predefined 
hard-wired 
logic or micro- 


code, the user has total flexibility in defining the 
functions the intelligent 
slave will assume in the 


overall system. 


Although 
the 
contents 
of an intelligent 
slave 


make 
it look very 
similar 
to a single 
board 


computer, 
the assumption 
of the slave role pro- 


vides a distinct advantage. 
By performing 
duties 


for a. master 
single 
board 
computer, 
the slave 


relieves the master of low-level processing 
duties 


and at the same time is itself relieved of system 
responsibilities. 


In order to position 
the iSBC 544 product 
and 


outline what features it brings to the application 
system 
it is necessary 
to define 
the functions 


involved 
with communicating 
data. 
The three 


main functional 
divisions 
are illustrated 
in Fig- 


ure 1. At the lowest level the physical 
intercon- 


nection 
is maintained. 
This level involves 
such 


standards 
as RS232C which defines the require- 


ments for transmitting 
bits from point to point. 


The data transmission 
level involves the transfer 


of bytes and/or 
blocks of data 
from devices to 


computers 
and from node to node in computer 


networks. 
The hardware 
dependent 
software 


such as interrupt 
service 
and 
device polling is 


I I I I 


I I I I 


part 
of this 
level as are handlers 
for standard 


protocols such as SDLC, HDLC, Bisync and X.25 
or special purpose schemes and custom protocols. 


The highest 
level performs the actual processing 


of the data and calls upon the lower levels to move 
the 
data 
from place 
to place. 
The application 


software resides at this level as do some high level 
software 
functions 
such as program 
to program 


and process to process communications 
packages. 


Now that we have a map of system functions 
to 


guide us, it is possible to gain an understanding 
of 


the 
usefulness 
of a product 
like the iSBC 544 


Intelligent 
Communications 
Controller. 
If an 


iSBC 534 board 
(which 
contains 
four USART 


devices) was included to handle 
the expansion 
of 


serial 
110 capacity 
the 
mapping 
of system 


functions 
would look like that 
shown 
in Figure 


2. The four USARTs on the board would handle 
the physical interconnection 
but due to the lack of 


intelligence 
on the board the master 
CPU would 


be burdened 
with 
all of the data 
transmission 


duties in addition to its real duty, data processing. 


When an iSBC 544 board is used in the system, 
the mapping 
of system 
functions 
is as shown in 


Figure 
3. The 
physical 
interconnection 
is still 


handled 
by the USARTs on the board but now the 


on-board CPU can be programmed 
to assume the 


data 
transmission 
duties. 
With 
an 
intelligent 


slave in the system, 
the master 
CPU is freed to 


concentrate 
on the data processing 
functions 
and 


the end result is that each function in the system 
is handled 
in the most efficient manner 
possible. 
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Figure 2. Mapping of System Functions with 


ISBC 534 Board 
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Figure 3. Mapping of System Functions with 


ISBC 544 Board 


The 
iSBC 
544 Board 


The 
iSBC 
544 
Intelligent 
Communications 


Controller 
contains: 


• An Intel 8085A CPU operating 
at 2.76 MHz. 


• Sockets for up to 8K bytes of read only memory 


(user 
can 
choose 
Intel 
2716, 2316E or 2732 


devices). 


• 16K bytes 
of dynamic, 
dual 
port 
Random 


Access Memory (RAM). 


• 256 bytes of static 
local RAM. 


• Four Intel 8251A USARTs with programmable 


baud rates. 


• Two Intel 8253 Programmable 
Interval Timers. 


• Intel 
8155 parallel 
interface 
providing 
22 
parallel 
I/O 
lines 
and 
one 
14 bit interval 


timer. 
Various 
input 
and 
output 
lines 
are 


dedicated 
to provide an interface 
to a Bell 801 


or equivalent 
Automatic 
Call Unit (ACU). 


• 8259A Priority 
Interrupt 
Controller. 


III. HARDWARE 
CONSIDERATIONS 


This section of the application 
note will focus on 
the 
iSBC 
544 hardware 
and 
will outline 
the 
features 
of the board and its uses. Appendix 
A 


contains 
simplified 
logic diagrams 
of the iSBC 


544 board which can be referenced in the follow- 
ing discussions. 


Two 
Mode 
Operation 


The iSBC 544 board is capable of operating in one 
of two modes; 1) intelligent 
slave and 2) stand- 


alone communications 
computer. 
The mode can 
either be set with a switch or it can be "toggled" 
via a software 
driven flip-flop on the board. 
In 
the intelligent 
slave mode the CPU on the iSBC 
544 board 
operates 
strictly 
within 
its on-board 
resources. 
Communications 
with 8-bit and 16-bit 
master 
single 
board 
computers 
is accomplished 


through 
the dual 
port 
memory. 
Since 
the on- 
board CPU executes code out of its local PROM 
program 
storage 
the system 
designer 
is free to 
define which functions 
the slave will assume in 


the 
system 
design. 
As discussed 
earlier, 
this 


could 
include 
all or part 
of the 
system 
data 
transmission 
duties or could involve application 
specific duties 
such as terminal 
format 
control, 
code conversion 
or terminal 
input editing. 


In the stand-alone 
mode, the logic on the board 
disables 
off board access to the dual port RAM 
and the bus buffers are used to allow the on-board 
CPU to access expansion 
memory and 110 on the 


MULTIBUS 
system bus. In this mode the iSBC 


544 board drives 
the bus busy (BUSY /) control 
line 
active 
disallowing 
any 
other 
bus master 
access to the bus. The stand-alone 
communica- 


tions computer is capable of performing 
all of the 


functions 
of the applications 
system. 
Referring 


once again 
to the diagram 
of the functions 
of a 


communication 
system, the stand-alone 
commu- 
nications 
computer, 
with 
or without 
system 


expansion, 
is responsible 
for all data 
transmis- 
sion 
and 
data 
processing 
functions. 
In small 
applications 
requiring 
multiple 
serial 
lines 
the 


stand-alone 
iSBC 544 controller 
is a perfect fit. 


In very 
special 
circumstances 
it is possible 
to 


share 
the system 
bus by toggling 
the mode set 


flip-flop between master and slave mode. Figure 4 


Figure 
4. iSBC 544 Controller 
Running 
ISBC 204 


Disk Controller 


shows the flow chart for a routine 
(code in 


Appendix B) that makes use of the "software 
switch" to operate an iSBC 204Diskette Control- 
ler. Using the iSBC 544 board in a system with 
DMAdevicesis not recommended except in cases 
where DMA accesses are short and relatively 
rare. The use ofthe CPU for the handling ofother 
system 
devices could seriously 
degrade 
its 


performance as a communications 
controller. 
However, this capability 
could be extremely 
useful in a system such as a small message store 
and forward where the disk traffic is not heavy 
and including a CPU card just to handle the disk 
would be wasteful. Use of the "software switch" 
to share the bus with another iSBC CPU is not 
advised because of the amount of protocol that 
would be required to keep the CPUs frominterfer- 
ing with each other on the bus. 


Dual Port RAM 
Figure 5 illustrates the dual port RAM memory 
array on the iSBC 544card. A triple bus architec- 
ture is used to allow other MULTIBUS bus 
masters access to the RAM on the intelligent 
slave. Both the on-board CPU's bus and the 
MULTIBUS system bus are connectedto the dual 


port controller. From here the dual port bus is 
connected to the 16K of dynamic RAM memory. 
Memory transfer requests from either of the first 
two busses are handled by the dual port control 
logic with the on-board CPU being given priority 
if contention arises. The local CPU is favored so 
that it is not overly delayed in handling its time 
critical functions. 


The address mapping of the dual port memory on 
the iSBC544is diagrammed in Figure 6. The user 
can enable access from the MULTIBUS system 
bus to 0, 4K, 8K or all 16K of the RAM on each 
iSBC 544 board. The dual port control logic 
decodes the full 20-bit address and provides an 
8-bit data path to the bus. For these reasons the 
iSBC 544board is compatible with 8080A,8085A 
and 8086based single board computers. The user 
can also select the block of addresses on the 
system bus to which the iSBC 544 RAM will 
respond. 
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When accessed by the on-board CPU, the dual 
port RAMalways appears at 8000H. If the iSBC 
544board is operating in the stand-alone compu- 
ter mode, the board is capable of generating the 
16-bit bus address supported by the 8085ACPU. 


Interrupt 
Structure 


The interrupt structure of the iSBC544controller 
is designed to handle the heavy load imposed by 
the inherent real-time nature of the communica- 
tions application. An 8259A Priority Interrupt 
Controller handles the fourreceiverand transmit- 
ter ready interrupts from the 8.251Adevices and 
provides vectored interrupts using one of many 
available priority schemes. In addition to the 
eight interrupt sources handled by the 8259there 
are various others that can be connected directly 
to the vectored interrupt inputs on the 8085A 
(RST 5.5, 6.5, 7.5 and TRAP). One interrupt is 
generated by the dual port control logicwhenever 
a byte is written into the base address of the dual 
port memory by an offboardCPU. This interrupt, 
the flag interrupt, is cleared automatically when 
the on-board CPU reads the byte and is useful 
when designing a master-slave protocol since it 
provides a unique interrupt to each slave in the 
system. 
If the 8251A devices are used to interface to 
modems the loss of carrier and ring indicator 
interrupts 
from all four channels need to be 


connectedto 8085Ainterrupt request inputs. This 
is accomplished with four input OR gates tying 
the eight sources into RST 6.5. The ring indicator 
and carrier detect lines can also be monitored 
through a parallel I/O port. This port would be 
read in a polled system to determine status or 
couldbe used along with the OR-tiedinterrupts to 
determine which channel is sourcing the current 
interrupt. 
The remaining interrupt sources come from the 
extra timer/counters and from the MULTIBUS 
interrupt lines. In addition to receivinginterrupts 
from the bus, the iSBC 544 board has the 
capability of generating MULTIBUS interrupts 
using the Serial Output Data (SOD) line on the 
8085ACPU. 


Modem and Autocall 
Interface 


The iSBC 544 controller uses 8251A and 8155 
devices for interface to modems and an autocall 


unit respectively. All of the necessary handsha- 
king signals concerned with the modeminterface 
are connected to the 8251Aand the carrier detect 
and ring indicator signals, as previously mEm- 
tioned, can be connected to interrupt inputs. The 
8155parallel ports are wired as shown in Figure 
7. Allofthe commonlyused signals definedin the 
EIA RS-366 specification for interface to an 
autocall unit a-':)provided. The software neces- 
sary for handling the ACU becomes a simple 
matter of responding to the ACU requests and 
sending out the BCD digits representing 
the 


number being dialed. In addition to the ACU 
interface, the 8155monitors various signal states 
and provides software reset capabilities for the 
USARTs and some interrupts. 


IV. SOFTWARE CONSIDERATIONS 
Software for the iSBC 544 ICC falls into three 
main categories; device programming, master- 
slave protocols, and communications support. 
Each of these three topics is covered in the 
following section with the aim of defining the 
software requirements and functions of the iSBC 
544 board. 


Device Programming 
The main sources of the power and flexibility of 
this product are the programmable LSI deviceson 
the board. The first duty ofthe on-boardsoftware 
is programming 
these devices to handle the 


specific task at hand. To start with, the 8251A 
USART can be programmed for synchronous or 
asynchronous operation. In synchronous mode 
the user specifieseven,oddor no parity and either 
external or internal sync detect with one or two 
sync characters. In the asynchronous mode the 
programmer selects the parity, the character 
length (5,6, 7 or 8 data bits), the framing control 
(1, 1'/2or 2 stop bits) and the baud rate scaling 
factor (input clock frequency divided by 1, 16 or 
64). 
The 8253Programmable Interval Timers provide 
the receiver and transmitter 
clocks for the 


USARTs and, along with the 8251A baud rate 
scaling factor, are programmed by the software to 
providethe desiredcommunications frequency.In 
addition, two additional 16 bit timers are left 
available to the applications programs to be used 
as event counters, real-time interrupts, etc. 
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The 
8259A 
Priority 
Interrupt 
Controller 
is 
programmed 
to vector all interrupts 
through 
a 
jump table in memory. Also, the device provides 
software 
selectable 
priority 
schemes 
and 
an 
interrupt mask register for sophisticated 
interrupt 
management 
designs. 


Last, 
but 
not least, 
the 8155 Programmable 
Peripheral 
Interface 
provides 
various 
software 


controlled input and output ports as discussed in 
previous sections. 
One specific point to remember 


is that the power on state of the 8155 clamps the 
reset signal to the USARTs active and must be 
removed by programming 
the 8155 before com- 


munications 
can begin. 


Master-Slave 
Protocols 


If an application 
system 
is visualized 
at the 
highest 
level it appears 
to be a computer 
with 
various inputs and outputs as depicted in Figure 
8a. If this computer is broken down into a master 
CPU and 
one or more intelligent 
slaves, 
great 
increases 
in efficiency 
and 
system 
throughput 


can be realized by distributing 
the duties between 
the 
CPUs 
(Figure 
8b). Once this 
split 
is per- 
formed, some well defined means of communica- 
tion 
between 
master 
and 
slaves 
needs 
to be 
defined so that the processes that execute on the 
different machines 
can cooperate. This means of 
communication 
takes 
the 
form 
of a protocol 
followed by both master 
and slave. 


INPUTS • 
APPLICATION 


SYSTEM 


• 
OUTPUTS 


The intelligent 
slave architecture 
was designed to 
simplify 
the 
development 
of the 
necessary 
protocol. The shared 
memory space in the dual 
port 
RAM provides 
a large 
communications 
buffer 
area 
where 
data 
and 
commands 
can be 


transferred 
using normal memory transfers. 
Data 
structures 
of any needed complexity 
can be built 
in this memory area and accessed by both master 
and 
slave. 
The 
flag 
interrupt 
can be used 
to 
provide a unique synchronization 
signal from a 


master to a given slave. In addition, the MULTI- 
BUS interrupt 
lines can be used to provide extra 
signals 
in both directions. 
As we shall see in the 
system software 
section, these basic tools can be 


utilized to design a general purpose data transfer 
mechanism 
which 
isolates 
the 
applications 
processes 
from 
the worries 
of protocols 
and 


synchronization. 


Communications 
Support 


The previous 
software 
topics dealt mainly 
with 


the system overhead that must be handled 
by the 


communications 
processor. 
The larger and more 


important 
duty of the CPU is dealing 
with the 


application 
at hand-communications. 


When configured 
as an intelligent 
slave to some 


master 
iSBC 
CPU 
board, 
the iSBC 544 board 


works to offload the master 
of communications 


related 
functions 
and at the same time is itself 
relieved of a major share of the system overhead 
and can be tuned to provide the highest 
possible 


throughput. 
With this 
combination, 
more com- 


plex 
applications 
can 
be tackled 
where 
the 
number 
of lines 
and 
the line frequencies 
are 


greatly 
increased. 
Multiple 
systems 
can 
be 
employed to provide a network 
facility with the 


iSBC 
544 board 
now 
handling 
the 
network 
protocol 
in addition 
to its other 
duties. 
The 


architecture 
of the iSBC 544 controller is designed 
to simplify 
the user's 
software 
development 
process. The board can be programmed 
to handle 
many possible data transmission 
functions 
from 


simple line protocols 
to terminal 
control to link 
protocols and all the way up to network protocols. 


In the stand-alone 
mode, the iSBC 544 board can 


assume 
total 
responsibility 
for the application. 
This can be done with on-board resources only or 
can include the support of offboard expansion 
like 


the iSBC 534 four chal1nel serial controller. Appli- 


cations of the stand-alone 
controller could include 


cluster 
controllers, 
peripherals 
managers, 
line 


concentrators 
or any other small system. 


V. THROUGHPUT 
ANALYSIS 


This 
section 
of the application 
note deals 
with 


studies 
that 
have 
been 
done 
to quantify 
the 


performance 
of the iSBC 544 board in both the 


stand-alone 
and intelligent 
slave modes. 
After 


describing 
the various 
test 
configurations 
and 


assumptions 
the 
data 
will 
be presented 
in 


graphical 
form and analyzed. 
The graphical 
data 
can be found in Appendix 
C. 


Stand 
Alone 
Throughput 


The 
first 
two tests 
were run 
to determine 
the 


absolute 
best case throughput 
of the iSBC 544 


board configured as a stand-alone 
computer. 
Fig- 


ure 9a shows the iSBC 544 controller continuously 
outputting 
data 
from four buffers 
to the four 


USARTs. 
Figure 
9b shows essentially 
the same 


setup with eight channels, 
four on the iSBC 544 


board 
and 
four 
on the 
iSBC 
534 expansion 


card. In each configuration 
the 8251A was run in 


synchronous 
mode and the baud rate was incre- 


mented 
until the transmitter 
empty signal 
from 


the USARTs became active. 
Further 
increments 


of the baud 
rates 
would 
not have 
resulted 
in 


higher 
throughput 
since the CPU was already 


spending 
100%of its available 
time responding 
to 


USART service requests. 


The maximum 
rate 
for the 
first 
configuration 
(iSBC 
544 board 
only) 
was 
32,311 
baud 
per 


channel. 
When the iSBC 534 expansion 
board 


was added a rate of 12,186 baud per channel 
was 


achieved. 
The drop in baud rate was due to the 


extra 
processing 
required 
by the offboard 
logic 
(eg. reading 8259 interrupt 
controller on the iSBC 


534 board to determine which device is requesting 
service). 


It should be noted that the serial throughput 
tests 


were run with almost no overhead 
and no actual 


processing 
of the data 
involved. 
The reader 
is 


expected to apply information 
on the amount 
of 


overhead expected in each individual 
application. 


For instance, 
if the application 
code for a given 


system is expected to utilize approximately 
40%of 


the available 
CPU time and we wish to run four 


iSBC 
544 


BOARD 


iSBC 
534 
BOARD 


full duplex channels in asynchronous mode the 
estimate of maximum baud rate would take the 
following form. 


32,331baud per channel - 40%= 19,398.6baud 
19,398.6baud per channel synchronous x 10/8 
= 24,248.25baud asynchronous 
24,248.25 baud per channel half duplex/2 = 
12,124.125full duplex 


Therefore, the maximum standard 
baud rate 


would be 9600 baud per channel in full duplex 
asynchronous mode. 


Intelligent Slave Throughput 
The remaining four configurations were set up to 
determine the effectivenessofthe intelligent slave 
in the overall system. The general system config- 
uration is illustrated in Figure 10. The boards 
surrounded by the box represent the systems 
under test. The disk controller and two iSBC 
80/20 single board computers were active on the 
bus to simulate the normal bus traffic load in an 
application system. Various bus duty cycleswere 
created using the computers and the disk control· 
ler to perform tasks that resulted in fixed bus 
utilization. 


Figure 10. General System Configuration for 
Throughput Testing 


In each configuration a single full duplexchannel 
was set up with the input provided by another 
CPU. Only those functions dealing with system 
overhead were included and the data measured 


reflected the amount of bus time, master CPU 
time and slave CPU time left available 
to 


applications oriented tasks. In each case this 
percentage oftime available was measured as the 
baud rate was stepped up so that a graph couldbe 
constructed showing time available as a function 
of transmission speed. 


CPU free time was measured using a counting 
program running in the background. After each 
USART interrupt the counter was started. As 
interrupts from other sources came in the count· 
-ing was preempted 
and then resumed after 


servicing the interrupt. When the next USART 
interrupt 
occured, the counter contents were 


examined and if the value was lower than the 
stored value the current value became the stored 
value. After ten minutes the stored value was 
retrieved and used as an indicator of the worst 
case time available between interrupts. 


System bus utilization was measured using the 
circuit shown in Figure 11. The voltage measured 
by the digital 
voltmeter 
represented 
a time 


average of the voltage at the output of the flip- 
flop. A calibration 
chart was created using a 


pulse generator to simulate various duty cycles 
and then this chart was used to measure bus 
activity while the test was running. 


Configuration 
1 is shown in Figure 12. This 


system uses a typical method of communications 
expansion with the iSBC 80/30 single board 
computerhandling the lines directly via the serial 
I/O ports on the iSBC 534 I/O controller board. 
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The second configuration (Figure 13) illustrates 
the performance of the traditional DMAcontrol- 
ler approach. If the communications controller 
had DMAlogicinstead of a dual port memory and 
transferred data directly into system memory the 
performance would be as observed in this ~est. 


In configuration 3 (Figure 14)the iSBC 544board 
was used in the intelligent slave mode. This 


configuration differs from the second in that 
memory transfers involved only local memory 
and bus access was not required 
on a 'per 


character basis. 
The fourth and final configuration 
sought to 


identify the loading that additional intelligent 
slave controllers would impose on master CPU 
time and bus free time. Figure 15 shows the 
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configuration with two iSBC 544 boards execut- 
ing identical programs. 


The graphical presentation of the results is split 
into two sections. The first three graphs (Graph 1 
through Graph 3) show the relationship between 
baud rates and the master CPU, system bus, and 
slave CPU utilization. All of these results are 
based upon tests with 30%induced bus traffic (i.e., 
the two iSBC 80/20 computers and the iSBC 204 
disk controller were active.) 


In graph 4, processor free time is graphed as a 
function of bus traffic. The processorin this case 
is the one actually involvedwith the data on a per 
character basis (i.e., iSBC 80/30 board in con- 
figuration 1, iSBC 80/30 board simulating DMA 
Controller in configuration 2,and iSBC544board 
in configuration 3). 


Finally, graph 5 illustrates the maximum attain- 
able baud rate for each configuration as the bus 
traffic is increased. 


All of the graphs identify the relative perfor- 
mance difference between the configurations. 
Absolute numbers are not presented due to the 
fact that 
the overhead imposed by the test 


software affects the CPU time being measured. 
Since the overhead applies equally to all config- 
urations, the relative performanceindications are 
valid. 


Based upon the data presented, the DMAcontrol- 
ler and intelligent slave use 3times less CPU time 
than 
an 110 controller. 
Also, the iSBC 544 


intelligent slave generates 12%and 6%less bus 
traffic than the I/O controller and DMAcontrol- 
lerrespectively. Finally, the intelligent slave uses 
8%less slave CPU time than the DMAcontroller 
approach. 


The earlier discussion that dealt with the intelli- 
gent slave architecture 
pointed out that the 


distribution 
of intelligence would offload the 


master CPU so that it would retain sufficient 
processing' power for the actual application, 
whatever that may be. In addition, it was stated 
that ~heassumption ofthe slave rolewouldrelieve 
the slave CPU of system overhead and at the 
same time reduce system bus traffic. All of these 
assumptions are supported by the results of the 
testing presented here. 


The second set of graphs identify the effects of 
bus traffic on the performance of the various 
components of the system. The main observation 
to be made in this sequence is the drop in CPU 
free times and maximum baud rates that occurs 
when the bus gets busy. This effectis observable 
in the communications processor free time when 
the iSBC 534 expansion 
board or the DMA 
controller configuration 
is used. No effect is 
evident in the configuration with an iSBC 544 
board. 


The cause of this effect is the amount of bus 
access required by each configuration to movethe 
characters 
from the USART to or from the 
buffer. With an iSBC 534board the master CPU 
receives an interrupt, polls the offboard 8259 
interrupt controller,reads in a character, stores it 
in system memory and sends an end of interrupt 
command to the offboard interrupt controller. 
When the iSBC 80/30 
computer receives an 
interrupt 
all processing is performed onboard 
until a bus access is required to move the data 
byte fromlto 
memory. In the case of the intelli- 
gent slave, all processing for a character 
is 


performed onboard. Thus, as the system bus 
becomes very fully utilized, the delays encounter- 
ed in receiving 
bus access by the first two 


configurations become significant. 


The fourth configuration, which was set up to test 
the effects of adding more intelligent slaves, 
shows that extra slaves cause no appreciable 
increase in system load. All of the data points for 
two slaves were identical to the points for one 
slave in graphs 1 through 5. 


VI. APPLICATION 
EXAMPLES 


A Distributed 
Control 
System 


The potential applications for a product like the 
iSBC 544 communications controller are almost 
unlimited and not restricted to the traditional 
Data Communications market. The first applica- 
tion example that is studied concerns industrial 
automation. Due to the fact that the system is 
distributed and requires a generalized network, 
the iSBC544board is a natural prospect to handle 
the communication links between the various 
nodes in the system. 


Design Requirements 
The system to be designed is intended to provide 
the framework for a family of distributed control 
systems where the configurations and the objects 
to be controlled vary from system to system. Fig- 
ure 16 shows the general picture of the system. 


Figure 16. General Diagram of Distributed 
Control System 


The host is responsible for providing supervisory 
control and a high-level human interface. The 
system can be expanded as shown in Figure 17 
where the controllers attached to the host are 
replaced by intermediate nodes which contain 
controllers or other nodes. This process can be 
continued as far as is necessary to provide the 
needed number of controllers. Each controller in 
the d,iagram represents a localized closed loop 
control system that is tailored to the specific 
application. 
The followingsystem requirements need to be met 
by the computer network: 


• The host CPU must have sufficient computa- 


tional power to handle the human interface, 
mass storage management, supervisory control 
calculations and network control. 


• The host CPU must not be overly burdened by 


low-levelcommunications functions if it is to 
handle the other duties assigned to it. 


• Node controllers must be capable ofhandling 8 


medium speed lines and also modems and 
autocall units since the nodes or controllers 
attached may be remote. 


• The message 
transmission 
format 
must 
be 


independent 
of the 
configuration 
and 
end 


application. 
The nodes in the network must be 


capable of passing through messages 
with and 


without 
interpreting 
the contained 
data. 


• The system must be capable of auto-configura- 
tion (since the network configuration 
is tailored 


to the specific 
application, 
the host must be 


able to automatically 
determine 
the setup at 


power on). 


• Each node controller 
is responsible 
for verify- 


ing the integrity 
of the nodes attached. 


System 
Configuration 


Based 
upon the design 
criteria 
and the bench- 


mark information 
the chosen configuration 
uses 


an iSBC 86/12 Single Board Computer as the host 
with an iSBC 544 intelligent 
slave handling 
the 


communications 
load for the CPU. The USART 


on the CPU board will talk to the local terminal 
and an iSBC 206 Hard 
Disk Controller 
will be 


used 
to provide 
up to 40 Megabytes 
of mass 


storage 
capacity. 


The requirements 
for the node controllers point to 


an iSBC 544 board configured 
as a stand-alone 


communications 
computer 
with 
an iSBC 534 


board 
as expansion 
to provide 
the necessary 
8 
lines. 
The 
throughput 
data 
indicated 
a raw 


throughput 
value of 12K baud on each channel. 


With the data rates expected being far below this, 
sufficient 
time will be left over for background 


functions. 
Thus, the software 
requirements 
for 


each node can all be met by the CPU on the iSBC 
544 board 
and 
the inclusion 
of an expansion 


board does not necessitate 
another 
iSBC compu- 


ter. 


A typical controller in the system would look like 
that shown in Figure 18. The iSBC CPU handles 
the local closed loop control, 
using parametric 


information 
sent from the host. This information 


would typically include setpoints, 
tolerances 
and 


alarm limits. 
The serial channel on the CPU will 


be used to maintain 
the link to the next level in 


the network. 


Preliminary 
Design 


The message 
format 
that 
the 
system 
uses is 


shown in Figure 19. When multiple nested levels 
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of nodes are used the data 
area of the message 


contains 
command 
and address 
information 
for 


the next level down (Figure 20). Interpretation 
of 


the commands 
in a given message is done on an 


individual 
basis except for a set of system-wide 


commands 
(eg. IDENTIFY 
is a system command 
meaning 
respond 
with your ID code). The flexi- 


bility afforded by this scheme can be extremely 
useful in a system where the end applications 
and 
configurations 
may be quite diverse (eg. a node 


controller that is processing 
a transmit 
command 
may be the only one that knows that it is sending 
to another 
node via 
a phone 
line and 
thus 
it 


interprets 
the contained 
data 
differently 
than 
another 
node would). 
The level of intelligence 


and 
the ease of programming 
of the iSBC 544 


board make this generalized transmission 
scheme 


possible. 


The simplest means of auto-configuration 
re- 
quires each controller in the system to send an 
identity message to the nearest node. This node 
would know the logical address of the controller 
that sent the message and would attach this 
address to the message and retransmit it to-the 
next levelas illustrated in Figure 21. This process 
would be repeated until the host is reached and 
would contain, at this point, all necessary address 
information to reach the given controller. 


The human interface on the host would provide a 
mapping 
mechanism 
to attach 
meaningful 


symbolic names to the various nodes in the 
system. This labeling, along with the application 
specific control algorithms, make it possible to 
say something like "lower the temperature on the 
third 
floor to 68 
0 F". The host breaks 
this 


information down into setpoints and tolerances, 


uses the map to determine the path to the node(s) 
responsible for the third floor and transmits the 
information through the network. 


Each node controller in the-systemhas the added 
responsibility of verifying the integrity of all the 
nodes attached to it. This duty can be handled by 
periodic background commands issued from the 
host and propagated through the network. Each 
node is responsible for passing the command 
along and also polling the nodes attached to it 
and reporting back any error conditions. 


Summary 
Through the use of a powerful 16-bit iSBC Single 
Board Computer, various low-cost 8-bit iSBC 
CPUs and the iSBC 544communications control- 
ler, a flexible and extensible distributed control 
system is easy to design. The dual nature of the 
iSBC 544board provides both an intelligent front 
end to the host computer and a high-speed stand- 
along nodal concentrator. The ability to individ- 
ually customize the software on each controller 
provides for an easily expandable system design. 


Terminal 
Cluster 
Controller 


The second application example concerns itself 
with a terminal cluster controller. The system 
shown in Figure 22 uses a number of "dumb" 
terminals and makes them appear "intelligent" 
via a local microcomputer system. The local 
microcomputer interfaces 'with the operator and 
accesses a local data base to provide an inquiry 
and data entry service. Whennecessary, the local 
microcomputer is capable of calling the host via 
an autocall unit and exchanging information and 
updates to the data base. 


Design Criteria 


The terminal cluster controller must meet the 
following criteria: 


• Support must be provided for from four to 


sixteen operator terminals all running at rates 
up to 2400 baud. 


• Line editing on input must be provided (delete 


characters, delete lines and pause output). 


LOCAL 
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• Support for the terminals 
must be configurable 


in that 
certain 
stations 
may require different 
screen formats. 


• Support for an optional hard copy device must 


be allowed for. 


• A considerable 
amount of CPU free time must 


be available 
after the basic terminal 
facilities 
are included. 
This is due to the fact that 
the 
data base management 
software to be written 


to run on the master single board computer will 
be extensive. 


• Type ahead would be a desired feature since the 
processing 
on the master 
CPU after a line of 


input has been transmitted 
may cause a delay 
in responding 
and we would like to have the 
ability to continue entering input while waiting 
for the response. 


System 
Configuration 


The specific iSBC products needed to implement 
the system 
described 
are the iSBC 80/30 Single 


Board Computer 
with an iSBC 032 RAM Expan- 


sion Board, 
an iSBC 206 Hard 
Disk Controller 


and one to four iSBC 544 Intelligent 
Communica- 
tions 
Expansion 
boards. 
Intel's 
RMX/80 
Real- 


Time Multitasking 
Executive 
will provide 
the 


basis 
for the software 
system 
and will include 


disk 
file support 
for the 
iSBC 
206 controller 


through 
DFS/80. 
The full system 
configuration 
is illustrated 
in Figure 23. 


Figure 23. Terminal Cluster Controller System 


Configuration 


Preliminary Design 


The first design decision to be made involves the 
distribution 
of system 
functions. 
Due to the 


requirements 
for line-editing 
and type-ahead 
the 


software for processing 
characters 
input from the 


terminal 
keyboards 
will be somewhat 
lengthy. 
The standard 
terminal 
output 
handler 
will be 


very 
small 
but 
provisions 
for special 
screen 


format controls and/or 
hard copy devices must be 


allowed for. All of these requirements 
lead to the 


use of the iSBC 544 controller 
for all terminal 


functions. 
If the master CPU were burdened with 


all ofthese duties it would be unable to adequately 
perform 
its data 
base 
management 
functions. 
The fast CPU and 8K PROM capacity ofthe iSBC 
544 board will be more than adequate for the task 
at hand. 


The throughput 
tests 
indicate 
that 
the loading 


imposed by expanding 
the number 
of terminals 


(and therefore 
the number 
of iSBC 544 boards) 


will not adversely 
affect the performance 
of the 


rest of the system. 
Master CPU free time and bus 


traffic 
data 
for two intelligent 
slaves 
in the 


system 
were identical 
to the numbers 
for one 


slave. Thus, 
since the iSBC 80/30 single board 


computer 
and 
the MULTI BUS system 
bus can 


handle 
one iSBC 544 controller 
they 
can 
also 


handle the maximum 
of four controllers that may 


be required by this application. 
The only observ- 
able effect will be caused by the load the extra 
operators impose on the data base software itself. 


The software 
needed for the iSBC 544 board is 


now defined and divided into three major pieces; a 
terminal 
input handler, a terminal 
output handler 


and 
system 
software 
to support 
the handlers. 
Since the input and output handlers 
are invoked 


via USART interrupts, 
all that need be done is to 


write a single routine for each handler and have it 
talk to all of the devices on the board. This can be 
accomplished 
by vectoring 
the proper interrupts 
to the entry point of the routine and then polling 
the 8259A interrupt 
controller to determine which 


device needs servicing. 


The 
standard 
terminal 
input 
handler 
needs 
to 
read in the available 
character 
from the USART, 


check it to see if it is a special command character 
and, if not, store it into a buffer. If a command 
character 
is encountered, the handler will respond 


by performing 
the appropriate 
operation. 


The standard 
terminal 
output 
handler 
simply 


takes 
characters 
out of a buffer upon interrupt 


from 
the 
transmitter 
and 
sends 
them 
to the 


appropriate 
USART. If a different output handler 


needs to be substituted 
for a special terminal 
or a 


hard 
copy device, a new routine 
can be included 


by modifying 
the interrupt 
vector address in the 


8259A jump table. 


Since 
the 
RMX/80 
Real-Time 
Multitasking 


Executive is being utilized on the master CPU it is 
desirable 
to create 
an RMX/80 
handler 
for the 


iSBC 
544 boards 
that 
accepts 
and 
processes 


normal 
terminal 
handler 
request 
messages. 
In 


this 
manner, 
application 
tasks 
that 
formerly 


communicated 
with the on-board USART via the 


RMX/80 Terminal 
Handler can be made to talk to 


one of the 
devices 
on the iSBC 544 board 
by 


simply changing 
the address of an exchange. The 


following paragraphs, 
as well as paragraphs 
in 


the section on system software, 
assume 
a know- 
ledge of the RMX/80 Real-Time Executive. 
This 


knowledge is not necessary to use the information 
contained 
in this 
application 
note. 
Interested 


readers 
are referred 
to the RMX/80 
references 


listed in the front-piece. 


Since this application 
can have from one to four 


iSBC 544 boards the RMX/80 driver will need to 
be configurable. 
A set of tasks 
and exchanges 


will be created 
for each terminal 
in the system. 


One task 
and 
exchange 
pair 
will accept 
and 


process 
terminal 
input 
request 
messages 
while 


another 
pair 
will process 
terminal 
output 
re- 


quests. 


The remaining 
piece of software that is needed by 


this 
system 
will provide the means 
for getting 


commands 
and 
data 
between 
the master 
and 


intelligent 
slave. Since this is a common need in 


any system utilizing 
an intelligent 
slave we will 


develop a general 
purpose 
scheme 
that 
can be 


used 
by any 
application. 
In this 
manner, 
a 


routine such as the terminal 
input handler 
can be 


written without any concern for how it will get the 
data it is ~nputting to the master CPU; all it need 
do is call upon a standard 
routine 
to "transmit" 


the data. With these thoughts 
in mind, the 


following section discusses the system software 
developed for master-intelligent slave communi- 
cation. After the discussion of the system soft- 
ware we will revisit the software for the second 
application as an example of the use of the data 
transfer routines. 


In the earlier discussion ofmaster-slave protocols, 
the notion was presented of developing a general 
purpose data transfer schemewhich wouldenable 
the applications routines on both the slave and 
master to operate without concerning themselves 
with protocols and synchronization. This scheme 
can be implemented 
by designing 
a set of 


primitive routines to handle the data transfer 
activities. Thus, Figure 8b is expanded as shown 
in Figure 24 and the applications processes now 
call upon the primitives to handle the communica- 
tions between the master and the slave. 


Data Transfer Primitives 
The basic mechanism used by this implementa- 
tion of the primitives is a wraparound queue as 
shown in Figure 25. Each 8251A device has 
associated with it, in dual port memory,an input 
and an output queue each of which have a give 


Figure 25. Wrap-around 
Queue Used by Deta 


Transfer 
Primitives 


and a take pointer. The give pointer contains the 
address of the next location in the queue that is 
available for filling with data. The take pointer 
contains the address of the next byte in an output 
queue that has been filled and is available. A 
queue is empty when the give and take pointers 
are equal and it is full when the act of incre- 
menting the give pointer would make it equal to 
the take pointer. A wrap function is defined to 
increment a pointer such that an increment past 
the bottom of the qUeue "wraps" the pointer 
around to the top of the queue. 
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Figure 24. System Software 
Diagram with Deta Transfer 
Primitives 


The primitives all make use of a queue informa- 
tion block located at the base address of the 
slave's dual port memory (Figure 26). All pointer 
information is base relative to accommodate the 
needs of the two CPUs who have different 
memory maps. The two flag bytes carry informa- 
tion for master-slave and slave-master synchron- 
ization signals. 


The set of primitives 
provides two distinct 


methods of information transfer, line oriented 
and byte oriented. The line oriented primitives 
are listed in Table 1. Both get$line and send$line 
transfer 
information between the queues and 
buffers provided by the caller. The disadvantage 
of this scheme is the number of memory moves 
needed to transfer information. The advantages 
of the line oriented method are the relative 
efficiencies and the simplicity of the interface 
from the calling routine. 


The byte oriented primitives (Table 2) allow the 
calling routine to transfer data directly into and 
out ofthe queues. An example of the sequencefor 
putting a character into a queue is illustrated in 
Figure 27. The routine servicing the receiver 
ready interrupt calls next$space to get a pointer to 
the next available slot in the queue and then uses 
this pointer to transfer the data byte directly into 
the queue. The new$line, xmit, open$line and 
receive primitives are necessary since the global 
give and take pointers cannot be modified until 
all manipulations on the affected section of the 
queue are complete. If the pointers were modified 
continuously the routine gathering the data from 
the other side may see invalid data. 
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Table 1 


Line Oriented Primitives 


Primitive 
Arguments 
Usage 


send$/ine 
Queue$token, 
buf$ptr, count 
Inserts count 
characters 
into queue from buffer 
Returns: overflow 
If insufficient 
room available, overflow indicates how many would not fit 


get$/ine 
Queue$token, 
buf$ptr. count 
Retrieves count characters 
from queue and puts them in buffer 


Returns: Actual 
Actual indicates how many were actually moved 


The remaining primitive routines deal with the 
general purpose needs of the application software 
with regard to interrupts, initialization and status 
checking. A full list of these support routines is 
contained in Table 3. 


There are many features of this implementation 
and a few of them should be pointed out at this 
time. By defining 
a general 
purpose set of 


primitive routines to handle the data transfer, the 
actual means by which the bytes are transferred 
between slave and master is not visible to the 
calling routine. If the actual mechanism used 
needs to be altered the change will not affect the 
application software as long as the same external 
interface is maintained. 


Another 
important 
feature 
of the primitive 


routines is the fact that they do not interpJ,'etthe 
bytes that are sent to them. Due to this fact, the 
applications routines are free to send commands 
and parameters 
interspersed 
with the actual 


data. As an example, the terminal driver on an 
iSBC 544 board might perform format control 
based upon table information. The master appli- 
cations software could use the data transfer 
primitives to transmit commands and parameters 
to the slave to update its format control informa- 
tion. Another advantage of the fact that the data 
is not interpreted is that it allows the calling 
routine to determine what data gets sent along. 
For instance, 
a specific terminal 
might 
be 


transmitting 
ASCII code while the master 


Table 2 


Byte Oriented 
Primitives 


Primitive 
Arguments 
~ " 
Usage 


new$line 
Queue$token 
Sets up a queue 
for byte oriented 
input. 


Returns: ptr 
Ptr returned 
points 
to the first 
available 
byte. 


next$space 
Queue$token 
Increments 
the temporary 
give pointer 
to the next open space. 


Returns: ptr 
Ptr returned 
either points to next byte or is zero specifying 
full queue. 


back$space 
Queue$token 
Decrements 
temporary 
give pointer. 


Returns: ptr 
Ptr returned 
either 
points 
to byte or is unchanged 
indicating 
that the 


global 
give pointer 
was reached. 


xmit 
Queue$token 
Closes 
off a line entered 
via byte mode by updating 
global 
give ptr to 


Returns: status 
equal temporary 
give ptr. 
Status 
is either 
"normal" 
or "null". 


open$line 
Queue$token 
Opens 
up a line for byte oriented 
output. 


Returns: ptr 
Ptr returned 
either 
points 
to the next byte or is zero 
indicating 
an 


empty 
queue. 


next$char 
Queue$token 
Increments 
temporary 
take pointer. 


Returns: ptr 
Ptr returned 
either 
points 
to next byte or is zero indicating 
an 


empty 
queue. 


receive 
Queue$token 
Closes 
off a line retrieved 
in byte mode 
by updating 
global 
take 
Returns: status 
pOinter to equal 
temporary 
ptr. 
Status 
is either 
"normal" 
or "null". 


Table 3 


Support 
Routines 


Primitive 
Arguments 
Usage 
. , 


get$status 
Queue$token 


, 


Returns 
status 
of queue. 
Possible 
values 
are "normal", 
"empty", 


Returns: status 
"full" 
and "null". 


set$interrupt 
Queue$token, 
type 
Generates 
a slave - 
master or master - slave interrupt. 
Type code 0 
Returns: status 
is illegal 
and codes 8H - 
OFH are reserved 
for use by the primitives. 


set$handler 
Queue$token, 
handler$adr 
Inserts 
address 
into vector 
table 
used for handling 
interrupts 
Returns: status 
described 
above. 


s$init 
none 
Called 
from 
slave software 
to initialize. 


m$init 
none 
- 
Called 
from 
master 
software 
to initialize. 


software is expecting EBCDIC. The routine on 
the slave can very easily perform the necessary 
code conversion before stuffing the data into a 
queue. 


Sample Slave Software 
Given the existence of the primitive routines the 
applications routines on the slave and master can 
deal with the specific duties of each device. The 
following paragraphs 
revisit 
the code from 
application example 2,first forthe slave and then 
for the master. 
Full code listings 
for these 
programs can be found in Appendix D. 


The flowchart for the terminal input handler 
resident on the iSBC544board is shown in Figure 
28. Support is provided for deleting characters 
(Rubout),deleting lines (control-X),pausing and 
resuming output (control-S and control-Q) and 
terminating lines (escape and carriage return). 
The sections of code reproduced below use this 
terminal input handler to present an example of 
the use ofthe data transfer primitives to enter and 
edit a line of input from a terminal. The byte 
variable value is based on the address variable 
value$ptr 
which is assigned 
by calls to the 
primitives. 
The routine 
var$inp 
inputs 
and 
returns a data byte from an I/O port specifiedby 
a calling parameter. This is necessary since the 
particular USARTto be servicedis determinedby 
reading the 8259Ain-service register. 


new$Ptr~b8Ck~space(token); 
if 
new$ptr=lengtn~Ptr 
then 
dummy=ecno(tokentl,.(oell1,1); 


else 
do; 
dummy=echo(tokentl,.(8S,SP,BS),~); 
ptr=new$ptri 
count=count-l; 
end; 


an invalid RUBOUTthe real pointer is assigned 
the value of the temporary pointer and a back- 
space, space, backspace is echoed to delete the 
previous character 
on the screen. Lastly, the 


character 
count for the current line is decre- 


mented. 


VALUE~PTR=NEXT$SPACE(QUEUE$NUMBER) 
; 


VALUE=VAR$INP 
(LlSART:;iDA'rA$PORT 
(NUM) ) ; 


Following this, the byte input is checkedto see if 
it is a control character and if so a blockwithin a 
DO CASE statement is executed. As an example 
of one of these blocks,if the character input was a 
RUBOUT the code sequence below is executed. 
The back$space primitive is called and a tempo- 
rary pointer is returned to a location in the queue. 
A check is made to determine if the line was 
empty and, if so, a bell is echoed to signal the 
Figure 28. Flow Chart for Terminal Input Handler 
operator. If the pointer returned did not indicate 


queue at a given time is limited only by the length 
ofthe queue. When a full line of input is finished, 
the terminal input handler generates a slave to 
master interrupt to signal the master routine who 
may be waiting for this event. 


In order to facilitate 
retrieval 
of the proper 


amount of information on the master side, the 
first byte of each message is defined to contain 
the number of characters in the message. Thus, 
when the master routine needs a line of input he 
uses the first byte as a count to retrieve the full 
line. The requirement for type-ahead is met by 
this mechanism since the number of lines in the 
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The flowchart for a minimal terminal output 
handler is shown in Figure 29. Upon receipt of a 


transmitter ready interrupt the output handler 
requests a character from the appropriate queue. 
If one is available it is output to the USART. If 
the queue is empty, the transmitter is disabled. 
Wheneverthe master routine sends a line into the 
queue it will generate an interrupt to signal the 
slave handler and the transmitter will be reen· 
abled. A line is openedvia a call to open$line and 
it is kept open until 100 characters have been 
retrieved via calls to next$byte. 
At this time the 
line is closedby a call to receive making the space 
available to be reused. After this, a new call to 
open$line 
starts the process over again. If the 


call to get$status 
shows that the queue was full 
prior to the call to receive, an interrupt is sent to 
the master to reawaken any routine that may 
have been waiting for room in the queue to 
become available. 


Sample Master Software 
The RMX/80 
handler for the master single board 


computer that will communicate with the soft· 
ware on the iSBC 544 board is diagrammed in 
Figure 30. In addition, the RMX/80 message used 
to conveyinformation to the handler is shown on 
the right. The full software diagram is illustrated 
in Figure 31. 


The input driver tasks executea reentrant routine 
that services a request exchange that is specified 
in an initialization block that is unique to each of 
the input tasks. The necessary information is 
extracted 
from the request message 
and the 


get$line primitive is called upon to get a line of 
input from the queue. If the call toget$line for the 
length byte is unsuccessful the input task waits at 
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the appropriate 
signal exchange 
for an interrupt 


from 
the 
slave 
indicating 
that 
a line is now 


available. 
Once the request is fulfilled the actual 


and status fields are set and the message is sent to 
the response 
exchange 
specified by the user. 


The output handler 
performs 
in a manner 
very 


similar 
to the input handler. 
Upon receipt of a 


request message the handler 
attempts 
to transfer 


the 
characters 
from 
the 
user 
buffer 
to the 


appropriate 
queue. If the attempt is unsuccessful 


(ie. the queue has insufficient 
room available) the 


handler 
sends 
as many 
characters 
as will fit 


(count - overflow) and then waits for an interrupt 
from the slave indicating 
that 
room has 
been 


made available. 
This process is repeated until all 


of the data has been transmitted. 
As soon as the 


operation 
is complete the status 
field is cleared 


and the message is returned 
to the user specified 


response 
exchange. 


Since 
the 
number 
of iSBC 
544 slaves 
in the 


system 
is variable 
as are 
the 
memory 
base 


address, 
device programming 
information 
and 


queue sizes, some means of providing 
configura- 


tion 
information 
to the 
RMX/80 
handlers 
is 


needed. 
This 
information 
resides 
in the mem- 


ory$allocation$module. 
Public 
variables 
are 


declared 
in this 
module 
that 
are used 
by the 


RMX/80 
tasks 
to determine 
how many 
devices 


(and therefore how many tasks need to be created) 
are in the system and where in the system address 
space their dual port RAM is located. 
In addition, 


queue sizes and device programming 
information 


are specified here. 


VIII. 
SUMMARY 


The intent 
of this 
application 
note has been to 


introduce 
the 
reader 
to the 
concept 
of the 


intelligent 
slave 
architecture 
and 
show 
the 


versatility 
of the first product 
based upon this 


architecture, 
the iSBC 544 Intelligent 
Communi- 


cations 
Controller. 
The hardware 
and software 


aspects of the device were studied and results of 
benchmark 
tests 
were presented 
and 
studied. 


Finally, 
two example 
applications 
were worked 


out 
using 
the 
product 
as both 
a stand· alone 


controller 
and as an intelligent 
slave. 


The bottom line is that the iSBC 544 controller, 
due to the advanced architecture around which it 
is designed, can be the means to the end for any 
application that requires communication. The 
dual nature of the controller provides the full 
power of a single board computer to the small 
application while the large system can make use 


ofthe fullyprogrammabale intelligent slave to free 
the CPU for complicated processing duties. 


I would like to extend my gratitude to Dave 
Jurasek for the work on the throughput testing 
and to Jack Tyler Inman for aid in the design of 
the system software. 
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3EIl! 


0029 
D381 


0il2B CD0000 
002E 
3E02 
0030 
D381 


0032 
D3E5 


1 $MOD85 
2 BASE 
3 MMSET 
4 MMRSET 
5 READ 
6 TCOUNT 
7 DMAMOD 
'3TADOR 
9 SADDR 
10 
11 BUFFER: 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
DSEG 
DS 


, 
ASEG 
ORG 
2CH 
OUT 
IN 
XRA 
CNZ 
EI 
RET 


EXTRN 
EXTRN 
EXTRN 
CSEG 
01 
LXI 
OUT 
CALL 
MVI 
OUT 
MVI 
OUT 
MVI 
OUT 
MVI 
OUT 
MYI 
OUT 
CALL 
MYI 
OUT 
CALL 
MYI 
OUT 
CALL 
MVI 
OUT 
OUT 


80H 
0E4H 
0E5H 
52H 
40FFH 
04H 
1 
2 


;BASE 
ADDRESS 
OF 
204 


;MASTER 
MODE 
SET 
ADDRESS 


:MASTER 
MODE 
RESET 
ADDRESS 


:READ 
COMMArm 
CODE 


;TERMINAL 
COUNT 
AND 
DMA 
MODE 
'OF 


;DMA 
MODE 
liORD 
;TRACK 
ADDRESS 
:SECTOR 
ADDRESS 


TEST 
OF 
CAPAaILITY 
FOR 
544 TO 
SHARE 
MULTI BUS 


WITH 
OTHER 
MASTERS. 
ROUTINE 
PROGRMIS 
THE 
204 


BOARD, 
INITIATES 
A READ 
TRANSFER, 
WAITS 
FOR 


AN 
INTERRUPT 
AND 
THEN 
TRAPS 
TO 
ICE85 
BREAK- 


POINT 
AT 
200. 


Ml'1SET 
BASE+l 
A 
ERRTRP 


;RST 
5.5 
ENTRY 
POINT 


;SET MASTER 
MODE 
;GET RESULT 
;SET 
FLAGS 
;NON-ZERO 
RESULT; 
ERROR 
TRAP 


;REENABLE 
;CONTINUE 
ON 


INI'T24 
WAITC 
WAITP 


;204 
INITIALIZATION 
ROUTINE 


;WAIT 
FOR 
204 NOT 
BUSY 
ROUTINE 


;WAIT 
FOR 
204 
PARAMETER 
REGISTJ 


SP,0BFFFH 
MMSET 
INIT24 
A,DMAMOD 
BASE+8 
A.LOW(TCOUNT) 
BASE+5 
A,HIGH(TCOUNT) 
BASE+5 
A, LOW (BUFFER) 
BASE+4 
A,HIGH(BUFFER) 
BASE+4 
WAITC 
A,READ 
BASE+0 
WAITP 
A,TADDR 
BASE+l 
WAITP 
A,SADDR 
3ASE+l 
Ml'1RSET 


;DISABLE 
;SET 
STACK 
POINTER 


:SET MASTER 
MODE 
FLIP 
FLOP 


;INITIALIZE 
204 
;SET 
DMA 
MODE 


8034 
FB 


Irlil35 
76 


0036 C30002 


0039 
76 


58 
EI 
59 
HLT 
60 
JMP 
2110H 
61 ERRTRP: 
62 
HLT 
63 
END 


ENABLE 
AND HALT 
; WAIT 
FOR INTEF 


TRAP TO ICE85 
BREAKPOINT 
AT 
20" 


ERROR TRAP 
FOR NOW 


PUBLIC 
SYMBOLS 


EXTERNAL 
SYMBOLS 


INIT24 
E 0000 
WAITC 
E 0000 
WAITP 
E 11000 


USER SYMBOLS 
BASE 
A 0080 
BUFFER 
D 0000 
OMAMOD 
A 11004 
ERRTRP 
C 0039 
INIT24 
E HUll 
MF 
READ 
A 0052 
SADi>R 
A 0002 . 
TADDR 
A 00111 
TCOUNT 
A 40FF 
WAITe 
E """Ill 
-WAI 


0080 
il0E4 
00E5 
0069 
0035 
0ill0 
001d 
00FF 
00FF 
000D 
0008 
0008 
0009 
4000 
0004 
1l0.~0 
01i20 
lhllll 


00110 F3 
0001 
3E0!:': 
0003 
30 
0004 
03E4 


00116 D38F 
0008 
3E01 
000A 
0382 


1l00C AF 
0000 
0382 
001lF CD9901l 
0012 
3E35 
0014 
0380 


0016 
CDA100 


0019 
3E00 
0Il1B 0381 
0010 
CDA100 
0020 
3E08 
0022 
0381 


0024 
CDA100 
0027 
3E08 
0029 
D381 


002B 
CDA1il0 
002E 
3U9 
0030 
D381 


0032 
CD99lHl 


1 $MOD85 
2 
BASE 
3 MMSET 
4 
MMRSET 


5 SEEK 
6 
SPECFY 
7 
BADTR1 


8 
BADTR2 
9 rlOBAO 


11; C'rADOR 
11 
CHARS 


12 
SETTLE 
13 
STEP 


14 
LOAD 


15 
TCOUNT 
16 
DMAMOD 


17 
BUSY 


18 
PARFUL 
19 
RESFUL 


20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
INI'r24: 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
H 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 


EQU 
EQU 
EQU 
EQU. 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


, 
CSEG 
PUBLIC 
PUBLIC 
PUBLIC 


DI 
MVI 
SIM 
OUT 
OUT 
MVI 
OUT 
XRA 
OUT 
CALL 
MVI 
OUT 
CALL 
MVI 
oU'r 
CALL 
MVI 
OUT 
CALL 
MVI 
OUT 
CALL 
MVI 
OUT 
CALL 


80H 
0E4H 
0E5H 
69H 
35H 
10H 
18H 
0FFH 
0FFH 
0DH 
08H 
1l8H 
1<l9H 
4000H 
1<l4H 
81<lH 
UJH 
11<lH 


BASE 
ADDRESS 
OF 
204 


MASTER 
MODE 
SET 
ADDRESS 


MASTER 
MODE 
RESET 
ADDRESS 


SEEK 
COMMAND 
·SPECIFY· 
COMMAND 
CODE 


SPECIFY 
BAD 
TRACKS 
SURFACE 
1 


SPECIFY 
BAD 
TRACKS 
SURFACE 
2 


NO 
BAD 
TRACKS 


CURRENT 
TRACK 
ADDRESS 
NOT 
KNOW~ 


SPECIFY 
DRIVE 
CHARACTERISTICS 


HEAD 
SETTLE 
TIME(SA800) 


STEP 
RNrE 
HEAD 
LOAD 
TIME 
TERMINAL 
COUNT 
AND 
DMA 
MODE 
'OF 


DMA 
MODE 
WORD 
21!!4BUSY 
MASK 


204 
PARAMETER 
REGISTER 
FULL 
AE 


204 
RESULT 
BYTE 
FULL 
MASK 


204 
INITIALIZATION 
ROUTINE. 
RESETS 
204 
BOARD 


AND 
PERFORMS 
ALL 
OF 
THE 
NECESSARY 
INITIALIZATIO~ 


OF 
THE 
8257 
AND 
8271. 


IrlI'r24 
WAITC 
WAITP 


Mi~SET 
BASE+15 
A,l 
BASE+2 
A 
BASE+2 
WAITC 
A,SPECFY 
BASE+il 
WAITP 
A, CHARS 
BASE+l 
WAITP 
A,STEP 
BASE+l 
WAITP 
A,SETTLE 
BASE+l 
WAITP 
A, LOAD 
BASE+l 
WAHC 


SET 
MASTER 
MODE 
FLIP 
FLOP 


RESE'r 
INTERFACE 


RESET 
204 


APPEI',IDIX 
B (Continued) 


0035 
3E35 
55 
MVI 
A,SPECFY 
lSPECIFY 
BAD TRAC~S 
01637 
03816 
56 
OUT 
BASE+il 
'''''39 
CDA1f60 
C 
57 
CALL 
WAITP 
, 
illl3C3E10 
58 
MVI 
A,BADTRI 
lBALlTRACKS 
FOR SURFACE 
1 
1603E 0381 
59 
OUT 
8ASE+l 
0040 CDAHI16 
C 
S~ 
CALL 
wAITP 
, 
01643 
3EFF 
61 
Mil 
A,NOBAD 
1FIRST TRACK· 


'hl45 0381 
62 
OUT 
BASE+l 
0047 CDAI160 
C 
63 
CALL 
WAITP 
. 
0~4A 
3EFF 
64 
MVI 
A,NOBAD 
lSECOND 
BAll 'rRACK 
01l4C 0381 
65 
OUT 
BASE+l 
IUl4E COAHJ0 
C 
66 
CALL 
WAI'rP 
0"51 
3EFF 
67 
MVI 
A,CTADLlR 
lCURRENT 
TRACK 
ADDRESS 
(NOT r ·O~ 
16053 
0381 
68 
OUT 
BASE+l 
11055 CD99011 
C 
69 
CALL 
WAI'rc 
11058 3E35 
70 
Mill 
A,SPECFY 


1l"5A 03811 
71 
OUT 
BASE+~ 
005C CDAl1l0 
C 
72 
CALL 
WAITP 
1 
'hl5F 3E18 
73 
MVI 
A,BADTR2 
lSURFACE 
2 
0061 0381 
74 
OUT 
BASE+l 
01163 CDA101i 
C 
75 
CALL 
WAITP 
1 
1111663EFF 
76 
MVI 
A,NOBAD 
lFIRST TRACK 
0068 
0381 
77 
OUT 
8ASE+l 
006A CDA100 
C 
78 
CALL 
WAI'rp 
, 
1611603EFF 
79 
MVI 
A,NOBAD 
1SECOND 
TRACK 
1l06F 0381 
80 
OUT 
BASE+l 
11071 CDAHIIl 
C 
81 
CALL 
WAITP 
1 
1111"14 
3EFF 
82 
MVI 
A,CTADOR 
lCURRENT 
TRACK 
ADDRESS 
(NOT r O~ 
11076 0381 
83 
OUT 
BASE+l 
111678C09900 
C 
84 
CALL 
WAITC 
1 
007B 
3E69 
85 
MVI 
A,SEEK 
lSEEK TO TRACK 
0 
11070 0380 
86 
OUT 
BASE+0 
0"7F COA100 
C 
'37 
CALL 
WAITP 
0082 
3E01l 
88 
MVI 
A,0 
0084 0381 
89 
OUT 
BASE+l 
, 
11"86 D3E5 
90 
OUT 
MMRSET 
;GO TO SLEEP 
WHILE 
2114DOES 
IT 
0088 
FB 
91 
EI 
lENABLE 
INTERRUPTS 
0089 
76 
92 
HL'r 
lSLEEP 
"08A 
F3 
93 
01 
10ISABLE 
008B 
3EIl4 
94 
MVI 
A,DMAMOO 
1SET OM/\.MODE 
0080 
D388 
95 
OUT 
BASE+8 
1 
008F 
3EIlll 
96 
MVI 
A,LOW(TCOUNT) 
lSET CONTROL 
REGISTER 
0091 0385 
97 
OUT 
BASE+5 
0093 3E40 
98 
MVI 
A,HIGH ('rCOUNT) 
0095 
D385 
99 
OUT 
BASE+5 
0"97 FB 
100 
EI 
, 
0098 C9 
101 
RET 
1RETURN 
1112 
103 
WAITC 
AND WAITP 
ROUTINES 
104 
1 
0099 DB80 
1115 WAITC: 
IN 
BASEHI 
GE'r STATUS 
BYTE 
009B E6816 
106 
ANI 
BUSY 
BUSY? 
0"90 C299"0 
C 
liii7 
JNZ 
WAITC 
YES,LOOP 
1l0A0 C9 
108 
RET 
NO,RETURN 
109 
, 
01lAl DB80 
110 WAITP: 
IN 
BASEHl 
GET STATUS 
REGISTER 
00A3 E620 
111 
ANI 
PARFUL 
PARAMETER 
BUFFER 
FULL? 
"0A5 C2AHl0 
C 
112 
JNZ 
WAITP 
YES,LOOP 
00A8 C9 
113 
RET 
NO, RETURN 
114 
END 


PUBLIC 
SYMBOLS 
INIT24 
C 11000 
WAITC 
C 10099 
WAITP 
C 00Al 


USER SYMaOLS 
BADTRl 
A 
16010 


INIT24 
C 
00016 


SEEK 
A 11069 


BADTR2 
A 0018 
LOAD 
A 0009 
SETTLE 
A BIl08 


BASE 
A 11080 
MMRSET 
A 00E5 
SPECFY 
A 0035 


BUSY 
MMSET 
STEP 


A 11080 
A 1l0E4 
A 01108 


CHARS 
A 000D 


NOBAD 
A 00FF 


TCOUNT 
A 4000 


GRAPH 1 
MASTER CPU FREE TIME 
VS BAUD RATE 
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GRAPH 2 
BUS FREE TIME 
VS BAUD RATE 


GRAPH 3 
SLAVE CPU FREE TIME 
VS BAUD 
RATE 
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GRAPH 4 
COMMUNICATIONS 
PROCESSOR 
FREE TIME 
VS BUS TRAFFIC 
@ 9600 BAUD 
FULL DUPLEX 


GRAPH 5 
MAXIMUM 
BAUD RATE 
VS BUS TRAFFIC 
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ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MODULE 
MAINLINE 


OBJECT 
MODULE 
PLACED 
IN 
:FI:MAINLN.OBJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:FI:MAINLN.PLM 
PRINT(:F5:MAINLN.LST) 
PAGEWIOTH(78) 


$title('slave 
mainline 
routine') 
main$line: 
DO; 


Mainline 
routine. 
Sets 
UP stack$ptr, 
calls 
s$init 
to 
init- 


ialize 
queues, initializes 
some 
of 
the 
hardware, 
sets 
up 
the 
initial 
flag 
interrupt 
handlers, 
and 
then 
halts 
with 
interru 


pts 
enabled 
allowing 
the 
rest 
of 
the 
system 
to operate 
totally 
in i~terrupt 
mode. 


initial$handler: 
PROCEDURE 
EX~ERNAL; 


END 
initial$handler; 


DECLARE 
command$word 
LITERALLY 
'41h', 
port$a$8155 
LITERALLY 
'0e9h', 
command$8155 
LITERALLY 
'0e8h', 
mask$8259 
LITERALLY 
'0e7h', 
icwl$8259 
LITERALLY 
'0e6h', 
icw2$8259 
LITERALLY 
'0e7h', 
ocw3$8259 
LITERALLY 
'0e6h', 
read$isr 
LITERALLY 
'0bh', 
mask$word 
BYTE 
PUBLIC, 
port$a$value 
BYTE 
PUBLIC, 
stat 
BYTE, 
i BYTE; 


output(icwl$8259)=0f6h; 
output(icw2$d259)=0fh; 
output (mask$8259) ,mask$word=0ffh; 


/* 
set 
up 8259 
for 
ISR 
reads 
*/ 


output(ocw3$8259)=read$isr; 


output (command$8155)=command$word; 
output(port$a$8155) 
,port$a$value=0c0h; 
DO 
i=0 TO 
7; 
stat=set$handler(i,.initial$handler); 


25 
2 
END; 


26 
1 
DO WHILE 
1; 
27 
2 
HALT; 
28 
2 
END; 


29 
1 
END main$line; 


CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
72 LINES 
READ 
" PROGRAM 
ERROR(S) 


004DH 
0004H 
01tl02H 


77D 
4D 
20 


ISIS-II 
PL!M-80 
V3.1 
COMPILATION 
OF 
MODULE 
INITIALHANDLER 


OBJECT 
MODULE 
PLACED 
IN 
:FI:FINTRT.OBJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:FI:FINTRT.PLM 
PRINT(:F5:FINTRT.LST) 
PAGEWIDTH(78) 


$title('slave 
application 
level 
signal 
handler') 


initiaI$handler: 
DO; 


Fields 
application 
level 
flag 
interrupts 
from 
the 


master. 
If the 
type=go$type 
the device 
attached 
to the queue 


specified 
is initialized 
with 
programming 
info 
sent 
into 


the queue 
by 
the master. 
If the 
type 
is data$available 
the 
specified 
transmitter 
is enabled 
unless 
a controI$s 
pause 


is in effect. 


DECLARE 
no$pause 
LITER~LLY 
'I', 
gO$type 
LITERALLY 
'1', 
data$available 
LITERALLY 
'2', 
enable$xmit 
LITERALLY 
'1', 
reset 
LITERALLY 
'40h', 
timer$I$command$port 
LITERALLY 
l~dbh', 
timer$2$command$port 
LITERALLY 
'0dfh', 
mask$8259 
LITERALLY 
'0e7h', 
mask$word 
BYTE 
EXTERNAL, 
mask 
(8) BYTE 
DAT~( 


0fch, 
0fch, 
0f3h, 
"'f3h, 
0cfh, 
0cfh, 
03fh, 
"'3fh), 
transmitter$state 
(8) BYTE 
PUBLIC, 
type 
BYTE, 
token 
BYTE, 
i 
BY'l'E, 
prog$info 
(5) BYTE, 
actual 
ADDRESS, 
~sart$command$port 
(8) BYTE 
EXTERNAL, 
usart$state 
(8) BYTE 
PUBLIC, 


Iength$pointer 
(8) ADDRESS 
PUBLIC, 
pointer 
(8) ADDRESS 
PUBLIC, 
char$count 
(8) 3YTE 
PUBLIC, 
timer$Ioad$oort 
(8) BYTE 
DATA( 


0d8h, 


33 
1 


34 
2 


35 
2 
36 
2 


37 
2 
38 
2 
39 
3 


40 
3 
41 
4 
42 
4 


43 
3 


44 
3 


45 
3 
46 
3 


47 
3 
48 
3 


49 
3 
50 
3 
51 
3 


52 
3 
53 
3 
54 
3 
55 
3 
56 
3 


57 
2 


58 
2 
59 
3 
60 
3 


61 
3 


0d8h, 
0d9h, 
0d9h, 
0dah, 
0dah, 
0dch, 
0dch) ; 


token=code 
AND 0fh; 


type=shr(code,4); 


IF type=go$type 
THEN 
DO; . 


transmitter$state(token)=no$pause; 


/* reset usart 
*/ 


DO i=0 TO 3; 
CALL varout(usart$command$port(token) 
,0); 


El~D; 


CALL varout (usart$command$port (token·),reset) ; 


actua1=get$1ine(token,.prog$info,5) 
; 


1* program 
the devices 
*/ 


CALL varout(usa~t$command$port(token) 
,prog$info(0)); 


CALL varout(usart$command$port(token) 
,usart$state(token) 


:=prog$info(1)) ; 
IF token 
< 7 THEN 
CALL varout(timer$1$command$port,prog$info(2)); 


ELSE 
CALL varout(timer$2$command$port,prog$info(2)); 


CALL varout(timer$1oad$port(token) 
,prog$info(3)); 
CALL varout(timer$1oad$port(token) 
,prog$info(4)); 


1ength$pointer(token-1)=new$1ine(token-1); 
pointer(token-l)=next$space(token-1); 
char$count(token-1)=0; 
output (mask$8259) ,mask$word=mask$word 
AND mask(token); 
END; 


ELSE 
IF 
(type=data$avai1ab1e) 
AND 
(transmitter$state(token)=no$pa 
use) THEN 
00; 


usart$state(token)=usart$state(token) 
OR enab1e$xmit; 


CALL varout(usart$command$port(token) 
,usart$state(token) 


RETURN I 
ENOl 


CODE 
ARJ;:A SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
154 
LINES 
READ 
111PROGRAM 
ERROR(S) 


illB2H 
11l043H 
011104H 


3860 
67D 
40 


ISIS-II 
PL/M-80 
V3.l 
COMPILATION 
OF 
MODULE 
INPUT HANDLER 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:INHDLR.OBJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:INHDLR.PLM 
PRINT(:F5:INHDLR.LST) 
PAGEWIOTH(78) 


$nointvector 
title('slave 
terminal 
input 
handler') 
input$handler: 
DO: 


544 
resident 
interrupt 
service 
routine. 
After 
receiver 


ready 
interrupt 
the 
8259 
In Service 
Re~1ster(ISR) 
is 


read 
to determine 
which 
device 
is requesting 
service. 


The 
character 
is read 
in and 
placed 
in the 
appropriate 


queue. 
A check 
is made 
for break 
characters 
ana 
appropriate 


action 
is taken 
if any 
are 
found. 
When 
an endline 
character 


is encountered 
the 
length 
byte 
is filled 
in 
( it was 
left 


vacant 
when 
the 
line 
was 
started) 
and 
the 
xmit 
primitive 
is 


called 
to update 
the 
global 
queue 
pointer 
to permit 
access 


to 
the 
line. 
At 
this 
time 
the master 
is signalled 
to signify 


that 
a new 
line 
is available 
for processing. 


DECLARE 
control$x 
LITERALLY 
'18H', 
control$s 
LIrERALLY 
'138', 
control$q 
LITERALLY 
'llH', 
rubout 
. 
LITERALLY 
'7FH', 
escape 
LI'rERALLY 
'lBH I, 
CR 
LITERALLY 
'00H', 
LF 
LITERALLY 
'0AH', 
as 
LITERALLY 
1~8H', 
SP 
LITERALLY 
'20H', 
bell 
LITERALLY 
'07H', 
?tr 
LITERALLY 
'pointer(token) 
" 
length$ptr 
LITERALLY 
'length$pointer(token) 
" 


count 
LITERALLY 
'char$count(token) 
" 


disable$xmit 
LITERALLY 
'0FEH', 
enable$xmit 
LITERALLY 
'01H', 
no$pause 
LITERALLY 
'1', 
pause 
LITERALLY 
'0', 
line$available 
LITERALLY 
'1', 
ocw2$8259 
LITERALLY 
'0E6H', 
ocw3$8259 
LITERALLY 
'0E6H', 
EOI 
LITERALLY 
'20H'; 


DECLARE 
value$ptr 
ADDRESS, 
value 
BASED 
value$ptr 
BYTE, 
line$length 
BASED 
value$ptr 
BYTE, 
dummy 
ADDRESS, 
ISR BYTE, 
token 
BYTE, 


37 
1 
38 
2 


39 
2 
41 
2 
43 
2 
45 
2 
47 
2 


49 
2 
51 
2 
52 
2 


53 
1 


54 
2 


55 
2 
56 
2 
57 
2 
58 
2 
59 
2 


60 
1 


61 
2 
62 
2 
63 
2 
64 
2 
65 
2 


66 
2 


67 
1 


68 
2 
69 
2 
70 
2 
71 
2 
72 
2 
73 
2 
74 
2 
75 
2 
76 
2 
77 
2 


stat 
BYTE, 
new$ptr 
ADDRESS; 


DECLARE 
pointer 
(8) ADDRESS 
EXTERNAL, 
length$pointer 
(8) ADDRESS 
EXTERNAL, 
char$count 
(3) BYTE 
EXTERNAL, 
usart$state 
(8) BYTE 
EXTERNAL, 
usart$command$port 
(8) BYTE 
EXTERNAL, 
usart$data$port 
(8) BYTE 
EXTERNAL, 
transmitter$state 
(8) BYTE 
EXTERNAL; 


index: 
PROCEDURE 
(value) 
BYTE; 
DECLARE 
value 
BYTE; 


IF value=control$x 
THEN 
RETURN 
0; 
IF value=rubout 
THEN 
RETURN 
1: 
IF value=control$s 
THEN 
RETURN 
2: 
IF value=control$q 
THEN 
RETURN 
3: 
IF value=escape 
THEN 
RETURN 
4; 
IF value=CR 
THEN 
RETURN 
5: 
RETURN 
6: 
END: 


DEC~~RE 
(buf$ptr,num$char,actual) 
ADDRESS, 
token 
BYTE: 


actual=send$line(token,buf$ptr,num$char) 
: 
usart$state(token)=usart$state(token) 
OR 
enable$xmit: 
CALL 
varout(usart$command$port(token) 
,usart$state(token»: 


RETURN 
actual: 
' 


END: 


length$ptr=new$line(token) 
; 
ptr=next$space(token) 
; 
count=0; 
dummy=echo(token+l,. 
('It' 
,CR,LF) ,3): 
RETURN: 
END: 


value$ptr=length$ptr; 
line$length=count: 
ptr=next$space(token) 
: 
stat=xmit(token) 
: 
length$ptr=new$line(token) 
: 
ptr=next$space(token) 
: 
count=0; 
stat~set$s$interrupt(token,line$available) 
: 
RETURN: 
END; 


78 
1 


79 
2 


80 
2 


81 
2 


82 
2 
83 
2 
84 
3 


86 
3 
87 
4 


88 
4 
89 
4 


90 
3 
91 
2 
92 
2 


93 
2 


94 
3 


95 
4 
96 
4 


97 
3 
98 
4 
99 
4 


100 
4 


101 
4 
Hl2 
5 


103 
5 


104 
5 


105 
5 


106 
4 


107 
3 
108 
4 


109 
4 


1111) 
4 
111 
4 


112 
3 


113 
4 


in$hdlr: 
PROCEDURE 
INTERRUPT 
0 PUBLIC; 
ISR=input(ocw3$8259) 
; 


again: 


ISR=sh 1 (ISR, 2) ; 


IF NOT 
carry 
THEN 
DO; 
IF token=0 
THEN 
RETURN; 
/* no bits 
set */ 


ELSE 
00; 
token=token-2; 
GOTO 
again; 
END; 


END; 


value$ptr=l?tr; 
value=varinp(usart$data$port(token)) 
AND 
07fh; 


CALL 
delete$line; 
EI'lD; 


new$ptr=back$space(token); 
IF new$ptr=length$ptr 
THEN 
dummy=echo(token+l,. 
(bell) ,1); 
ELSE 
DO; 
dummy=echo(token+l,. 
(BS,SP,BS) ,3); 


ptr=new$ptr; 
count=count-l; 


END; 


transmitter$state(token+l)=pause; 


END; 


/* case 
3; control$g; 
resume 
output 
*/ 


DO; 


114 
4 


115 
4 


116 
4 


117 
3 
118 
4 


119 
4 


12~ 
4 


121 
4 
122 
4 


123 
3 


124 
4 
125 
4 
126 
4 


127 
4 
128 
4 
129 
4 
130 
4 
131 
4 


132 
3 
133 
4 
134 
4 
135 
4 
137 
4 


138 
4 


139 
3 
140 
2 


141 
2 


142 
2 


143 
1 


transmitter$state(token+1)=no$pause; 
El~D; 


/* case 
4; 
escape; 
terminate 
line 
*/ 


DO; 
dummy=echo 
(token+1,. 
('# I ,CR,LF) ,3) ; 
va1ue=CR; 
count=count+1 
; 


CALL 
end$line; 


Ei~D; 


/* case 
5; 
carriage 
return, 
terminate 
line 
*/ 


uO; 
dummy=echo 
(token+ l, . (CR, LF) ,'2); 
count=count+1 
; 


ptr=next$space(token) 
; 


va1ue$ptr=ptr; 
va1ue=LF; 
count=count+1 
; 
CALL 
end$line; 


END; 


/* case 
6; 
non-break 
character; 
stuff 
into 
queue 
*/ 


DO; 
dummy=echo(token+1,ptr,l) 
; 


.'ptr=next$space 
(token) ; 
IF 
ptr=0 
THEN 
CALL 
de1ete$line; 
/* full 
buffer 
*/ 


ELSE 
count=count+l; 


END; 


END; 
/* of 
do 
case 
*/ 


output(ocw3$8259)=EOI; 


CODE 
AREA 
SIZE 


VARIA8LE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


255 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


0398H 
0011H 
~01filH 


9200 
17D 
16D 


ISIS-II 
PL/M-8~ 
V3.1 
COMPILATION 
OF 
MODULE 
OUTPUTHANDLER 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:OUTHLR.08J 


COMPILER 
INVOKED 
BY: 
PLM8~ 
:Fl:OUTHLR.PLM 
PRINT(:F5:0UTHLR.LST) 
PAGEWIOTH(78) 


$nointvector 
title('slave 
character 
output 
handler') 


output$handler: 
00; 


544 
resident 
interrupt 
service 
routine. 
After 
transmitter 


ready 
interrupt, 
825~ 
In Seriice 
Register(ISR) 
is read 
to 


determine 
which 
device 
is requesting 
service. 
A character 


is requested 
from 
the 
appropriate 
queue 
and, 
if available, 


is sent 
to the 
usart. 
If the 
queue 
is empty 
the 
transmitter 


is disabled 
pending 
a signal 
from 
the master 
when 
more 


characters 
are 
put 
into 
the queue. 


DECLARE 
ocw2$8259 
LITERALLY 
'IOE6H', 
ocw3$8259 
LITERALLY 
'0E6H', 
disable$xmit 
LITERALLY 
'lOFER', 
true 
LITERALLY 
'~FFH', 
false 
LITERALLY 
'0~H', 
EoI 
LITERALLY 
'IOAIOH'; 


DECLARE 
ISR BYTE, 
token 
BYTE, 
actual 
ADDRESS, 
value 
13YTE; 


DECLARE 
usart$state 
(8) BYTE 
EXTERNAL, 
usart$command$port 
(8) BYTE 
PUBLIC 
DATA( 
001H, 
IODIH, 
IOD3H, 
1003H, 
IOD5H, 
IOD5H, 
1007H, 
IOD7H), 
usart$data$port 
(8) BYTE 
PUBLIC 
DATA ( 
IOD0H, 
£IDIOH, 
~D2H, 
£ID2H, 
1004H, 


15 
2 


16 
2 


17 
2 


18 
2 
19 
2 
20 
3 


22 
3 
23 
4 
24 
4 
25 
4 
26 
4 
27 
3 


28 
2 
29 
2 
30 
2 
31 
3 


32 
3 


33 
3 


34 
2 
35 
2 
36 
2 
37 
2 
38 
1 


0D4H, 
0D6H, 
0D6H) 1 


PROCEDURE 
INTERRUPT 
1 PUBLICl 


/* get 
active 
level 
number 
and 
use 
it to determine 
queue$token 
* 
/ 


again: 
ISR=shl(ISR,l)l 
IF NOT 
carry 
THEN 
001 
IF token=l 
THEN 
RETUR~; 
/* no bits 
in ISR 
set */ 


ELSE 
001 
token=token-21 
ISR=shl(ISR,l) 
; 
GOTO 
again; 
END; 


actual=get$line(token,.value,l); 
IF actual=fO THEN 
001 /* empty 
queue. 
Disable 
transmitter 
*/ 


usart$state(token)=usart$state(token) 
AND 
disabl 


END; 
ELSE 
CALL 
varout(usart$data$port(token) 
,value); 


output(ocw3$8259)=EOI; 
RETURN; 
:::ND; 
END output$handler; 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


102 
LINES 
READ 


10PROGRAM 
ERROR(S) 


roiaMH 
0005H 
000CH 


164D 
50 
120 


ISIS-II 
PL/M-80 
V3.1 COMPILATION 
OF 
MODULE 
INIT544 
OBJECT 
MODULE 
PLACED 
IN 
:FI:INIT54.0BJ 


COMPILER 
INVOKED 
BY: 
PLMB0 
:Fl:INIT54.PLM 
PRINT(:F5:INI~54.LST) 
PAGEWIDTH(7B) 


$title('rmx/8~-544 
initialization 
task') 
init$544: 


DO: 


Task 
code 
for 
544 driver 
initialization 
task. 
Info 


from 
aoplication 
supplied 
memory 
allocation 
block 


is accessed 
to set 
up quepes 
and 
transfer 
device 
programming 


info 
to the 
slave 
board(s) 
and 
create 
the 
required 


service 
handler 
tasks. 


input$driver: 
PROCEDURE 
EXTERNAL: 
END 
input$driver: 


output$driver: 
PROCEDURE 
EXT~RN~L: 
END 
output$driver: 


signal: 
PROCEDURE 
EXTERNAL: 
END 
signal: 


DECLARE 
stack$size 
LITERALLY 


go$type 
LITERALLY 
'256 I, 
11' 
; 


DECLARE 
ptr 
ADDRESS, 
init$table 
BASED 
ptr 
STRUCTURE ( 
base$adr 
ADDRESS, 
queue$token 
BYTE, 
prog$info 
(5) BYTE), 
i 
BYTE, 
overflow 
ADDRESS, 
queue$init$table 
(1) STRUCTURE 
( 
base$adr 
ADDRESS, 
queue$size 
(8) ADDRESS)-£XTERNAL, 
initialization$table 
(1) BYTE 
EXTERNAL, 
stat 
BYTE, 
num$devices 
BYTE 
EXTERNAL, 
num$boards 
BYTE 
EXTERNAL, 
service$exchange$table 
(1) ADDRESS 
EXTERNAL, 


signal$exchange$table 
(1) ADDRESS 
EXTERNAL, 
service$exchanges 
(1) BYTE 
EXTERNAL, 
signal$exchanges 
(1) BYTE 
EXTERNAL, 
task$descriptors 
(1) BYTE 
EXTERNAL, 


65 
1 


66 
2 


67 
2 
68 
2 
69 
2 
7~ 
2 
71 
2 


72 
1 


73 
2 
74 
3 


75 
3 


76 
2 


77 
2 


78 
2 


79 
2 


80 
3 


8] 
3 


stac~s 
(1) BYTE 
EXTERNAL, 
info$block. (1),STRUCTURE ( 
base$adr 
ADDRESS, 
queue$token 
BYTE, 
index 
BYTE) 
EXTERNAL, 
rqactv 
ADDRESS 
EXTERNAL; 


DECLARE 
:om$input$std 
static$task$descriptor 
DATA( 
'input 
I, 


.input$driver, 
0, /* 
stack 
will 
be 
assigned 
individually 
*/ 


stack$size, 
2~0, 
0, /* tba */ 
~), 
/* 
tba */ 


rom$output$std 
static$task$descriptor 
DATA ( 


~output 
I , 
.output$driver, 


11 , 
stacksize, 
201, 
0, 
0) , 
input$hdlr$std 
static$task$descriptor, 
output$hdlr$std 
static$task$descriptor; 


init$xch: 
PROCEDURE 
(xch$ptr); 


/* 
initializes 
expanded 
interrupt 
exchanges 
*/ 


DECLARE 
xch$ptr 
ADDRESS, 
xch 
BASED 
xch$ptr 
int$exchange$descriptor; 


xch.link=.xch.link; 
xch.type=int$type; 
xch .length=5; 
RETURN; 
END; 


DO 
i=0 TO 
num$boards-l; 
CALL 
m$init(.queue$init$table(i)); 
END; 


CALL 
move(size(rom$output$std) 
,.rom$output$std,.output$hdlr$ 


std) ; 
ptr=.initialization$table; 


DO 
i=0 TO 
num$devices*2 
BY 
2; 


/* 
send 
pogramming 
info 
to slave 
*/ 


overflow=send$line(init$table.base$adr,init$table.queue$ 


token,.init$table.prog$info,5); 
stat=set$m$interrupt(init$tabie.base$adr,init$table.queu 


82 
3 


83 
3 


84 
3 
85 
3 
86 
3 


87 
3 


88 
3 


89 
3 
93 
3 
91 
3 
92 
3 


93 
3 
94 
3 
95 
3 
96 
3 
97 
3 
98 
3 


99 
3 
100 
3 
Hll 
3 
102 
3 


103 
2 
104 
2 
105 
2 
106 
2 


107 
1 


CALL 
rqcxch(service$exchange$table(i) 
:=.service$exchange 
s+liil*i); 


CALL 
rqcxch(service$exchange$table(i+l) 
:=.service$exchan 
ges+Hl* (i+l» 
; 
CALL 
init$xch (.signal$exchanges+15*i) 
; 


CALL 
init$xch(.signal$exchanges+15*(i+l»; 
CALL 
rgcxch(signal$exchange$table(i) 
:=.signal$exchanges+ 


CALL 
rqcxch(signal$exchange$table(i+l) 
:=.signal$exchange 


s+15* (i+1)); 


info$block(i) 
.base$adr, 
info$block(i+l) 
.base$adr=init$table.base$adr; 


info$block(i) .queue$token=init$table.queue$token-l; 
info$block(i+l) 
.queue$token=init$table.queue$token; 


info$block(i) 
.index=i; 
info$block(i+l) 
.index=i+l; 


input$hdlr$std.sp=.stacks+stack$size*i; 
output$hdlr$std.sp=.stacks+stack$size*(i+l) 
; 


input$hdlr$std.exchange$address=.info$block(i) 
; 


output$hdlr$std.exchange$address=.info$block(i+l); 
input$hdlr$std.task$ptr=.task$descriptors+20*i; 
output$hdlr$std.task$ptr=.task$descriptors+20*(i+l); 


CALL 
rqctsk(.input$hdlr$std); 
CALL 
rqctsk(.output$hdlr$std); 
ptr=ptr+8; 


END; 


CALL 
rqsetv(.signal,2); 


CALL 
rqelvl(2); 


CALL 
rqsusp(rqactv); 


END; 
/* of 
task 
*/ 


CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


285 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


02C3H i 
002AH 
01il06H 


707D 
42D 
6D 


ISIS-II 
PL!M-B0 
V3.1 
COMPILATION 
OF 
MODULE 
INITMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:MAB.OBJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:MAB.PLM 
PRmT(:F5:I.'!AB.LST) PAGEf.olIDTH(7B) 


$title('rmx!B0-544 
initialization 
module 
and memory 
allocation 
b 


lock' ) 
init$modu1e: 
DO; 


DECLARE 
nurnber$of$devices 
LITERALLY 
'4', 
baud$rate$count$l 
LITERALLY 
'32', 
baud$rate$count$h 
LITERALLY 
'~0', 
usart$mode 
LITERALLY 
'4eh', 
usart$cmd 
LITERALLY 
'27h', 
ctr$0$mode 
LITERALLY 
'36h', 
ctr$1$mode 
LITERALLY 
'76h', 
ctr$2$mode 
LITERALLY 
'0b6h', 
ctr$3$mode 
LITERALLY 
'36h', 
num$devices 
BYTE 
PUBLIC 
DATA(number$of$devices-1), 
num$boards 
BYTE 
PUBLIC 
DATA(l), 
service$exchange$table 
(B) ADDRESS 
PUBLIC, 
signa1$exchange$table 
(8) ADDRESS 
PUBLIC, 


signa1$type 
(8) BYTE 
PUBLIC, 
service$exchanges 
(80) BYTE 
PUBLIC, 
signa1$exchanges 
(120) BYTE 
PuBLIC, 
task$descriptors 
(160) BYTE 
PUBLIC, 
stacks 
(2048) 
BYTE 
PUBLIC, 
info$block 
(32) BYTE 
PUBLIC, 
queue$init$tab1e 
(1) STRUCTURE 
( 
base$adr 
ADDRESS, 
queue$size 
(8) ADDRESS) 
PUBLIC 
DATA ( 
0e0lMlh, 
256, 
1765, 
256, 
1765, 
256, 
1765, 
256, 
1765) , 
base$table 
(1) ADDRESS 
PUBLIC 
DATA ( 
0e000h) , 
initia1ization$table 
(number$of$devices) 
STRUCTURE 
( 
base$adr 
ADDRESS, 


queue$token 
BYTE, 
prog$info 
(5) BYTE) 
PUBLIC 
DATA ( 
0eiHH:lh, 
1, 
usart$mode, 
usart$cmd, 
ctr$0$mode, 
baud$rate$count$l, 
baud$rate$count$h, 


0e0 00h, 
3, 
usart$mode, 
usart$cmd, 
ctr$l$mode, 
baud$rate$count$l, 
baud$rate$count$h, 


0e0 0eJh, 
5, 
usart$mode, 
usart$cmd, 
ctr$2$mode, 
baud$rate$count$l, 
baud$rate$count$h, 


0e0 eJeJh, 
7, 
usart$mode, 
usart$cmd, 
ctr$3$mode, 
baud$rate$count$l, 
baud$rate$count$h) 
1 
END 
init$modulel 


CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
79 LINES 
READ 
~ PROGRAM 
ERROR(S) 


0eJ36H 
09B0H 
0eJeJeJH 


540 
24800 
00 


ISIS-II 
PL/M-8H 
V3.1 
COMPILATION 
OF 
MODULE 
SIG~ALHANDLER 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:SIGNAL.OBJ 


COMPILER 
INVOKED 
BY: 
PLM8H 
:Fl:SIGNAL.PLM 
PRINT(:F5:SIGNAL.LST) 
PAGEWIDTH(78) 


$nointvector 
title('slave->master 
interrupt 
handler') 


signal$handler: 
DO; 


DECLARE 
i 
BYTE, 
ptr 
ADDRESS, 
(flag BASED 
ptr) 
BYTE, 
num$boards 
BYTE 
EXTERNAL, 
num$devices 
BYTE 
EXTERNAL, 
signal$type 
(1) BYTE 
EXTERNAL, 
index 
BYTE, 
token 
BYTE, 
signal$exchange$table 
(1) ~DDRESS 
EXTERNAL, 
base$table 
(1) ADDRESS 
EXTERNAL; 


signal: 
PROCEDURE 
INTERRUPT 
2 PUBLIC; 


next: 
ptr=base$table(i)+l; 
IF 
flag=0 
THEN 
DO; 
i=i+l; 
IF 
i > num$boards 
THEN 
RETURN; 
/* erroneous 
signal 
* 


ELSE 
GOTO 
next; 
END; 


/* get 
queue 
token 
and 
use 
it to 
index 
into 
signal 
exchange 
tabl 


e 
*/ 


token=(flag 
AND 
0fh); 
index=4*i+token; 


39 
2 
IF index 
<= num$devices 
THEN 


4\l 
2 
DO; 


41 
3 
CALL 
rqisnd(signal$exchange$table(index» 
; 


42 
3 
signal$type(index)=shr(flag,4); 


43 
3 
END; 


ELSE 


44 
2 
CALL 
rqendi; 


/* zero flag to acknowledge 
interrupt 
*/ 


45 
2 
flag='"; 


46 
2 
RETURN; 


47 
2 
END; 


48 
1 
END signal$handler; 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
110 LINES 
READ 


'"PROGRAM 
ERROR(S) 


0\l8BH 
0005H 
001ilAH 


1390 
5D 
100 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MODULE 
INPUTDRIVER 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:INPUT.OBJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:INPUT.PLM 
PRINT(:F5:INPUT.LST) 
PAGEWIDTH(78) 


$title('rmx/80-544 
input 
service 
handler') 
input$d river: 
DO; 


Master 
resident 
task 
code. 
Monitors 
service 
exchange 


and 
fills 
input 
requests 
by 
retrieving 
characters 
from 
the proper 
queue(board$base 
and 
device 
info 
is passed 
via 
default 
exchange 
field). 
By definition 
the 
first 
byte 


of 
a line 
of 
input 
contains 
the 
length 
of 
that 
line. 


This 
figure 
is used 
to retrieve 
the 
exact 
number 
of 
characte 


DECLARE 
rqactv 
ADDRESS 
EXTERNAL, 
td 
BASED 
rqactv 
task$descriptor, 
service$exchange$table 
(1) ADDRESS 
EXTERNAL, 
signal$exchange$table 
(1) ADDRESS 
EXTERNAL; 


DECLARE 
service$exchange 
ADDRESS, 
board$base 
ADDRESS, 
queue$token 
BYTE, 
signal$exchange 
ADDRESS, 
msg$ptr 
ADDRESS, 
msg 
BASED 
msg$ptr 
th$msg, 
actual 
ADDRESS, 
dummy 
ADDRESS, 
info$block$ptr 
ADDRESS, 
info$block 
BASED 
info$block$ptr 
STRuCTURE ( 


base$adr 
ADDRESS, 
queue$token 
BYTE, 
index 
BYTE) , 
num$char 
BYTE, 
stat 
BYTE; 


info$block$ptr=td.exchange$address; 
/* default 
exchange 
fiel 


d 
*/ 


service$exchange=service$exchange$table(info$block.index); 


board$base=info$b1ock.base$adr; 
queue$token=info$b1ock.gueue$token; 
signa1$exchange=signa1$exchange$tab1e(info$b1ock.index) 
1 


DO forever; 


retry: 
/* try to get 
line 
count 
out of queue 
*/ 
actua1=get$line(board$base,queue$token,.num$char,1) 
1 


IF actua1=~ 
THEN 
DO; 
dummy=rqwait(signa1$exchange,0) 
; 
GOTO 
ret'ry; 
END; 


actua1=get$line(board$base,queue$token,msg.buffer$adr,nu 
m$charl; 
~sg.actua1=actua1; 
msg.status=r<l; 
CALL 
rqsend(msg.resp$ex,msg$ptr); 
ENOl /* of do forever 
*/ 


r<l12CH 
r<lr<lr<lr<lH 
r<lr<l17H 


3r<l0D 
00 
230 


CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
171 LINES 
READ 
r<lPROGRAM 
ERROR(S) 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MODULE 
OUTPUTDRIVER 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:OUTPUT.OBJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:OUTPUT.PLM 
PRINT(:F5:0UTPUT.LST) 
PAGEWIDTH(78) 


$title('rmx/80-544 
output 
service 
handler') 
output$driver: 
DO; 


Master 
resident 
task 
code. 
Monitors 
service 
exchange 
and 


fills 
output 
requests 
by stuffing 
characters 
into 
the 
approp 


riate 
queue. 
If 
insufficient 
room 
is available 
the 
task 
waits 
for 
1 second 
and 
retries 
up to 
100 times 
after 
which 
it 


signals 
a time 
out 
error. 
If the 
transmission 
completes 


successfully 
the 
slave 
is signalled 
to 
indicate 
that 
data 
is 


DECLARE 
data$available 
LITERALLY 
'2', 
time$out 
LITERALLY 
'I'; 


DECLARE 
rqactv 
ADDRESS 
EXTERNAL, 
(td BASED 
rqactv) 
task$descriptor, 
service$exchange$table 
(1) ADDRESS 
EXTERNAL, 


signal$exchange$table 
(1) ADDRESS 
EXTERNAL; 


DECLARE 
service$exchange 
ADDRESS, 
signal$exchange 
ADDRESS, 


base$adr 
ADDRESS, 
queue$token 
BYTE, 
msg$ptr 
ADDRESS, 
msg 
BASED 
msg$ptr 
th$msg, 
tries$left 
BYTE, 
overflow 
ADDRESS, 
dummy 
ADDRESS, 
stat 
BYTE, 
info$block$ptr 
ADDRESS, 


info$block 
BASED 
info$block$ptr 
STRUCTURE ( 
base$adr 
ADDRESS, 


queue$token 
BYTE, 
index 
BYTE) ; 


43 
2 
44 
2 
45 
2 
46 
2 
47 
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48 
2 


49 
3 
50 
3 
51 
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52 
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53 
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56 
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5 
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5 
62 
5 
63 
4 
64 
3 
65 
3 


66 
3 
67 
3 


68 
3 


69 
2 


70 
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info$block$ptr=td.exchange$address; 
service$exchange=service$exchange$table(info$block.index); 
signal$exchange=signal$exchange$table(info$block.index) 
; 
bas=$adr=info$block.base$adr; 
queue$token=info$block.queue$token; 


msg$ptr=rqwait(service$exchange,0) 
; 
tr ies$left=Hl0; 
retry: 
overflow=send$line(base$adr,queue$token,msg.buffer$adr,m 
sg.count) ; 
IF overflow 
<> 
0 THEN 
DO; 
dummy=rqwait(signal$exchange,20) 
; 
tries$left=tries$left-l; 
IF tries$left 
> 
0 THEN 
GOTO 
retry; 
ELSE 
DO; 
msg.status=time$out; 
msg.actual=0; 
GOTO 
quit; 
END; 
END; 
msg.status=0; 
stat=set$m$interrupt(base$adr,queue$token,data$availabIe 


CALL 
rqsend(msg.resp$ex,msg$ptr); 
END; /* of do 
forever 
*/ 
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INTRODUCTION 


Intel's single board computers 
and the MUL TIBUS™ 
system bus have become de facto industry standards 
in 
the microcomputer 
board market. The speed and capa- 
bility of the bus coupled with the functionality 
and per- 


formance of the boards have been used to solve a large 
number of problems. iSBC products are in applications 
ranging from simple single board relay replacement 
to 


sophisticated 
multi-board 
business systems supporting 
large hard disk files. However, even with the range of 
functionality 
provided 
by standard 
iSBCs and expan- 


sion boards, 
designers 
have felt the need to design 


custom MUL TIBUS-compatible 
boards to fit their ap- 
plication. 
Until the introduction 
of the iSBX concept, 
these custom 
boards 
had to be implemented 
using a 
separate MULTIBUS 
form factor board. 


Intel has recently introduced 
a new line of board prod- 


ucts ami " new bus which are destined 
to become 


another industry standard because of the niche they fill. 
The new iSBX MUL TIMODULE 
boards are designed 


to extend 
the functional 
capabilities 
of single board 


computers 
at a much lower cost than previously possi- 


ble. iSBX MUL TIMODULE 
boards are supported by a 
new bus - 
the iSBX bus, which allows the MUL TI- 


MODULE boards to be added directly to the on-board 
microprocessor 
bus. 
iSBX MUL TIMODULE 
boards 


are from 10 to 20 square inches in size, therefore permit- 
ting small modular 
increments to a single board com- 
puter's capabilities. 


System designers 
now have the capabilities 
of using 


either 
standard 
iSBCs 
or 
iSBX 
MULTIMODULE 
boards, or designing custom MUL TIBUS compatible or 
iSBX MUL TIMODULE 
boards. 
Cost-effective 
solu- 


tions are easily realized because of this added flexibility. 


This 
application 
note 
discusses 
the 
iSBX MUL TI- 


MODULE 
concept, 
currently 
available MUL TIMOD- 
ULE boards and the iSBCs which support these boards. 
The 
iSBX bus interface 
specifications 
are discussed 
next, followed by consideration 
for designing custom 
iSBX MUL TIMODULE 
boards. 
A specific design ex- 


ample using an Intel@ 8279 Programmable 
Keyboard/ 


Display Controller 
is presented. 


The objective of the note is to introduce 
the reader to 
the 
iSBX MUL TIMODULE 
concept 
for expanding 
iSBC functionality 
and to illustrate how a designer can 


effectively 
use this concept 
with either 
standard 
or 
custom iSBX boards. 


References to further documentation 
on the iSBX bus, 


specific iSBX MUL TIMODULE 
boards and iSBC host 
boards currently available may be found in the Related 
Intel Publications 
section in the front overleaf of this 
application 
note. 


iSBX™ MULTIMODULE™ 
BOARD 


CONCEPT 


The iSBX MULTIMODULE 
board concept was devel- 


oped to provide the users of Intel single board 
com- 
puters (iSBCs) with a convenient method to increment- 
ally expand the I/O or the computing 
capabilities of a 
single board computer. 
This expansion is done through 


the use of a new interface called the iSBX bus interface. 
This interface gives the user the capability of adding I/O 
mapped functions directly onto the microprocessor 
bus 


via plug-in modules that connect to the iSBC board by 
means of a special iSBX connector. 
With the use of this 


new bus interface, 
it is now possible to expand or add 


new features 
to your iSBC system without 
incurring 


large costs and long engineering development 
times. 


There are a number of unique advantages 
to using the 


iSBX bus interface 
for system expansion 
rather 
than 
adding 
a separate 
expansion 
board 
to your system. 


First, when expansion is required, the user needs only to 
buy what is required 
for the application. 
Second, it is 


now possible to return to one board solutions for small 
systems. One board solutions eliminate the need for ex- 
pensive backplanes and cardcages. Next, the iSBX inter- 
face connects 
directly to the microprocessor 
or local 
bus, as opposed to interfacing 
to the MUL TlBUS sys- 


tem 
bus, 
therefore 
I/O 
expansion 
does 
not require 


system bus cycles. To the CPU, the iSBX board looks 
like any other on-board 
I/O device (Figure I). Address 


decode logic exists on the iSBC host board 
for each 
iSBX connector on the host board. 


iSBe'" 
SINGLE 
BOARD 
COMPUTER 


Figure 1. iSBC™ Host Board Block Diagram 


Third, 
if there is no iSBC or MULTIBUS 
compatible 


expansion board available to fit the needs of your appli- 
cation or if the expansion boards available offer more 
capability than required, 
then it is possible to design a 


custom iSBX MULTlMODULE 
board. 
Custom iSBX 


boards offer several advantages 
over custom MUL TI- 


BUS boards: they require less board real estate (10 or 20 


square inches versus 81 square inches) and less engineer- 
ing design time; consequently, 
they cost considerably 
less to implement. 
Additional 
capability 
is therefore 
achieved with maximum productivity. 


Currently 
available 
Intel 
iSBX 
MUL TlMODULE 
Boards include: 


I) iSBX 350 Parallel 
I/O 
MUL TIMODULE 
board 


which contains 
24 programmable 
I/O lines with 


sockets for line drivers and terminators. 
2) iSBX 351 Serial 
I/O 
MULTIMODULE 
board 


containing 
one 
RS232 or RS449/422 
program- 


mable 
synchronous/asynchronous 
communica- 


tions channel and two timers. 
3) iSBX 331 Fixed/Floating 
Point 
Math 
MULTI- 


MODULE 
board which permits fixed or floating 
point mathematics 
via the Intel 8231 device. 


4) iSBX 332 Floating Point Math MUL TlMODULE 
board which permits floating point mathematics 
using the Intel and proposed 
IEEE floating point 


standards 
via an Intel 8232 device. 


With these iSBX MUL TIMODULE 
boards and other 


soon-to-be-announced 
boards, the capability now exists 
to economically 
tailor a single board computer 
to the 
application 
using off-the-shelf 
products. 


iSBX™ MULTIMODULE™ 
SYSTEM 


INTERFACE 


This section begins by describing the basic system ele- 
ments used in an iSBX MUL TIMODULE 
interface con- 


figuration and then defines the interface signals used for 
the communication 
between these elements. The specifi- 


cations contained 
in this application 
note are included 


for descriptive and tutorial purposes only. The ultimate 
source for this information 
is the iSBX Bus Specifica- 
tion which is referenced 
in the front overleaf of this 
note. 


The host board provides an electrical and mechanical in- 
terface for the iSBX expansion module. The host board 
is the master of the communications 
between the host 


and iSBX board, it controls the address and command 
signals. 


A new generation of iSBX bus compatible host boards 
are evolving. The first board available from Intel is the 
iSBC 80/IOB Single Board Computer. The 80/IOB con- 
tains an 8080A CPU operating at 2 MHz, IK bytes of 
RAM with sockets available for expansion to 4K bytes 
of RAM, sockets for up to 16K bytes of EPROM, 
24 
parallel I/O lines, a programmable 
synchronous/asyn- 
chronous 
communications 
interface 
and a fixed 1.04 
msec timer. The 80/IOB has one iSBX connector, 
per- 


mitting the use of an iSBX MUL TlMODULE 
board. 


The 
second 
iSBC board 
available 
supporting 
iSBX 
boards is the iSBC 80124 Single Board Computer. 
The 
80124 board, 
which supports 
two iSBX MUL TlMOD- 
ULE boards, 
contains an 8085A-2 CPU operationg 
at 
4.8 or 2.4 MHz, 4K bytes of RAM, sockets for up to 
32K bytes of EPROM, 48 parallel I/O lines, a program- 
mable synchronous/asynchronous 
communications 
in- 


terface, three programmable 
interval timers and a pro- 
grammable 
interrupt 
controller. 
Further 
RAM expan- 


sion on the 80124 board is accomplished by the addition 
of an iSBC 301 4K byte RAM MUL TIMODULE 
board 
which expands the RAM by an additional4K 
bytes for a 
total 
of 8K bytes. The iSBC 301 MUL TIMODULE 
board is not iSBX bus compatible; it is attached via pins 
and sockets in the RAM seCtion of the host board. 


iSBX™ MULTIMODULpM 
Boards 


The iSBX MUL TIMODULE 
boards communicate 
with 
the host boards via the iSBX bus interface. These iSBX 
boards are I/O mapped through pre-defined select lines 
to specific 
port 
addresses. 
The 
iSBX bus currently 
defines an 8-bit data path compatible 
with both 8 and 


16-bit future iSBC host boards. 
Examples of possible 


iSBX expansion boards include"a floppy disk controller, 
a 
cassette 
interface, 
analog-to-digital 
converter 
or 
digital-to-analog 
converter 
boards, 
an interface to the 
IEEE 488 Bus and a video graphics display interface 
board. 


There are two standard 
sizes of iSBX boards: a single- 


wide board measuring 
7.24 by 9.40 cm (2.85 by 3.70 
inches) and a double-wide 
l;Joard measuring 
7.24, by 
19.05 cm (2.85 by 7.50 inches). The iSBX MULTI- 
MODULE 
boards 
mount 
onto 
any 
microcomputer 
board 
containing 
an iSBX connector 
and 
mounting 
hole. The iSBX boards physically plug into the iSBX 
connector 
on the host board 
and are secured with a 
nylon stand-off 
and screws. The mounting 
hardware 
supplied as part of the iSBX board includes: 


I) One nylon spacer, 112n threaded 
2) Two nylon screws, 1/4" 6-32 
. 


3) One 
36-pin 
connector, 
factory-installed 
onto 
the 


iSBX module. 
(These may also b~ purchased 
from 


Intel.) 


The interconnection 
between the host board and iSBX 
board, as well as the mounting clearances, may be seen 
in Figures 2 and 3. 


NOTE 


The 
iSBX board, 
when 
installed 
onto 
a host 


board, occupies an additional card slot adjacent to 
the base board 
in an iSBC 604/614 
Cardcage. 


However, 
the base board may be inserted in the 
top card slot of the cardc,\ge. If this is done, no 
additional slots are required. 


/HOSTBOARD 


INTELISBX'· 
C::/..:::'. 
_MULTIMODULE'· 
/> 
CONNECTOR 
/~: .. 


I'r 


The iSBX interface connector 
is a 36-pin custom made 


connector that was designed by Intel especially for this 
interface. The connector is plastic with gold plated con- 
tact pins for maximum reliability. The connector for the 
iSBX interface was designed for high reliability and dur- 
ability. The connection between the host board and the 
iSBX MUL TIMODULE 
board was extensively tested 


for vibration, 
shock, humidity, and temperature 
to in- 


sure that the connection is rugged enough to be used in 
severe environments. 
This connection was tested for the 
following environment: 


Sweeping from 10 Hz to 55 Hz and back 
to 10 Hz at a distance of 0.010 inches 
peak-to-peak, 
lasting 15 minutes in each 


of the three planes. 


30g's of force for an ll-msec 
duration, 
three times in three planes, 
both sides 
(total of 18 drops). 


900/0 maximum 
relative 
(no condensa- 


tion). 


Temperature: 
0 to 55°C (32-131 OF) free moving air 
across 
the 
base 
board 
and 
the 
iSBX 


MUL TIMODULE 
board. 


Further 
information 
on the reliability testing that was 
done on this inter-connection, 
or reliability information 


on the iSBX MUL TlMODULE 
boards 
in general, 
is 
contained in the Reliability Report, RR-29, "Intel iSBX 
MULTIMODULE 
Boards 
and 
iSBC 
80/10B 
Single 


Board Computer," 
listed in the overleaf of this note. 


The male half of this connector is available from Intel in 
the form of the iSBX 960-5 package which contains five 
of the connectors. 


iSBX™ Bus Interface 
Signals 


The iSBX bus interface 
signals are grouped 
into six 
basic groups, or classes, according to the functions per- 
formed relative to the interface: 


These signals are: 


CONTROL 
LINES 
ADDRESS 
LINES 
DATA LINES 
INTERRUPT 
LINES 
OPTIONAL 
LINES 
POWER LINES 


Many of the signals on the iSBX bus are active-low, 
meaning a low level on a control signal of the bus indi- 
cates a logic" I" value, while a low level on an address 
or data signal of the bus represents a logic "0" 
value. 


In this application 
note, an active-low signal will 


be designated 
by placing 
a slash (I) 
after 
the 


mnemonic for the signal. 


Appendix A contains a pin assignment list of the follow- 
ing signals: 


The following signals are classified as control lines: 


I) COMMANDS 
- 
lORDI, 
IOWRTI 


2) DMA - 
DMRQT, 
MDACK/, 
TDMA 


3) INITIALIZE 
- 
RESET 
4) CLOCK - 
MCLK 
5) SYSTEM CONTROL 
- 
MWAIT/, 
MPSTI 


Command Lines (I/O READ, I/O WRITE) 


The command lines are active-low signals which control 
the communication 
link between the host board and the 


iSBX board. 
An active command 
line conditioned 
by 
chip select indicates to the iSBX board that the address 
lines are valid and the iSBX board should perform the 
specified operation. 


DMA Lines (MDRaT, 
MDACK/, TDMA) 


The DMA lines control the communication 
link between 
the DMA device on the host board and the iSBX mod- 
ule. DM,RQT is an active-high output 
signal from the 


iSBX board to the host board's 
DMA device requesting 
a DMA cycle. MDACKI 
is an active-low input signal to 


the iSBX board from the host board DMA device ac- 
knowledging 
that the requested 
DMA cycle has been 
granted. TOM A is used by the iSBC board to terminate 
DMA activity. The use of the DMA lines is optional as 
not all host boards will provide DMA channels nor will 
all iSBX boards be capable of supporting 
them. 


Initialize Line (RESET) 


This active-high input line to the iSBX board is gener- 
ated by the host board to put the iSBX board into a 
known internal state. 


Clock Line (MCLK) 


This input line to the iSBX board is a timing signal. The 
clock frequency 
is 10 MHz (+ 0%, 
- 10%), and the 
clock is asynchronous 
with respect to all other iSBX bus 
signals. 


System Control Lines (MWAIT/, MPST) 


These output signals from the iSBX board control the 
state of the system. Active MWArT I (active-low) will 


put the CPU on the host board into a wait state, provid- 
ing additional 
time for the iSBX board to perform the 


requested 
operation. 
MPST I is an active-low 
signal 


(usually tied to signal ground) 
that informs 
the host 


board I/O decode logic that an iSBX module has been 
installed. 


ADDRESS AND CHIP SELECT LINES 


The address and chip select lines are made up of the 
following signals: 


I) ADDRESS LINES - 
MAO, MAl, 
MA2 


2) CHIP SELECT LINES - 
MCSOI, 
MCSII 


Address Lines (MAO, MA1, MA2) 


These active-high 
input lines to the iSBX boards 
are 


generally the least three significant bits of the I/O ad- 
dresses. 
In conjunction 
with the command 
and chip 


select lines, they establish the I/O port address being ac- 
cessed. 


Chip Select Lines (MCSO/, 
MCS11) 


These active-low input lines to the iSBX board are the 
result of the host board I/O decode logic. When active, 
the MCSI 
lines condition the I/O command signals and 


thus enable communication 
between the iSBX board 


and the host board. 


DATA LINES (MDO-MD7) 


There are eight bidirectional 
data lines. These active- 


high lines are used to transmit or receive information 
to 


or from the iSBX ports. MOO is the least significant bit. 


INTERRUPT LINES (MINTRO, MINTR1) 


These active-high output lines from the iSBX board are 
used to make interrupt requests to the host board. These 
lines are jumper enabled and disabled on the host board 
via wire wrap posts. 


OPTION LINES (OPTO, OPT1) 


These two signals are reserved lines that are connected 
to wire wrap posts on both the host board and the iSBX 
MUL TIMODULE 
board. They are for unique require- 
ments where a user needs a host board or MULTIBUS 
bus signal on the iSBX module. 


All host boards provide + 5 volts as well as ± 12 volts to 
the iSBX MUL TIMODULE 
board 
along with signal 


ground. 
All power supply voltages are ± 5%. Table I 


gives the power supply specifications for the iSBX inter- 
face. 


Minimum 
Nominal 
Maximum 
Maximum 
(volts) 
(volts) 
(volts) 
(current)" 


+4.75 
+5.0 
+5.25 
3.0A 


+ 11.4 
+12 
+ 12.6 
LOA 


-12.6 
-12 
-11.4 
I.OA 


- 
GND 
- 
6.0A 


This section of the application note focuses on the iSBX 
interface and design considerations 
related to interfac- 
ing with the iSBX bus. It discusses the way the major 
operations 
like READ, WRITE, 
and DMA work, and 


the timing diagrams associated with each. There is also a 
discussion on other considerations 
for designing with 


the iSBX bus. 


Bus Timing 


The AC timing specifications for the iSBX bus interface 
can be found in Appendix B of this application 
note. It 


should be emphasized that the interface timing between 
the host board and the iSBX MUL TIMODULE 
board is 
very critical. This is largely due to the fact that the iSBX 
board is attached directly to the microprocessor 
bus. If 


the timing specifications are not met, unpredictable 
and 


possibly intermittent 
operation 
of the host board may 


result. 


Command 
Operations 


The command lines (lORDI, 
10WRT) are driven from 
the h,·'t board by three-state drivers with pull-up resis- 
tors or standard TTL totem-pole drivers. These lines in- 
dicate to the iSBX board that action is being requested. 
There are two types of operations 
for each command 


line and it is the iSBX board 
that determines 
which 
operation 
is to be performed. 


READ OPERATIONS (IORD/) 


Two different types of read operations are possible. The 
first type of read is called a full speed I/O READ. The 
host board generates a valid I/O address (MAO-MA2) 
and a valid chip select signal (MCSII) which is then sent 
to the iSBX board; after the set-up times are met, the 
host board activates the 10RDI 
line. At this time, the 


iSBX board 
must generate 
valid data 
from 
the ad- 
dressed I/O port in less than 250 ns. The host board 
then reads the data and removes the READ command, 
address and chip selects. These are shown in the timing 
diagram for this operation 
(Figure 4). The second type 


of read operation 
is called an I/O READ with Wait. 


This READ is used by iSBX boards that cannot perform 
a full speed read operation. 
Under this operation 
the 


host board generates the valid address and chip select 
signals, as in the full speed read. But this time the iSBX 
board will activate the MWAIT; signal, which in turn 
removes the READY input to the CPU, putting it into a 
Wait 
state. 
The 
CPU, 
however, 
first 
activates 
the 


lORD; 
signal before going into the Wait state. After 


valid data is placed on the iSBX data bus by the iSBX 
board, the iSBX board will remove the MWAIT; signal. 
The host board will then read the data and remove the 
command, 
address, 
and 
chip select lines. This 
I/O 


READ with Wait operation 
is shown in Figure 5. 


WRITE OPERATIONS (IOWRTI) 


There are also two types of write operations 
possible: 


the type performed 
is again determined 
by the iSBX 


board. In the full speed I/O WRITE operation, 
the host 


board generates a valid I/O address and chip select and 
then activates the IOWRT; 
line after the necessary set- 


up times are met. The 10WRT; 
line, after being acti- 


vated, will remain active for 300 ns and the data will be 
valid for 250 ns before the 10WRT; 
command 
is re- 


moved. The host board will ,then remove the data, ad- 
dress, and chip select lines after the hold times are met, 
lis shown in the timing diagram of this operation (Figure 
6). 


This second write operation 
is the I/O 
WRITE 
with 
Wait 
operation. 
This 
WRITE 
is used by the iSBX 


boards that cannot write into an I/O port with the full 
speed 
write 
specifications. 
The 
host 
board 
again 


generates valid address and chip select signals as in the 
full speed write operation. 
However, this time the iSBX 


board generates the MWAIT; 
signal based on address 


information 
(chip select and MAO-MAI). 
The activa- 


tion of MWAIT; causes the removal of READY to the 
CPU, thus causing the CPU to go into a Wait state. The 
iSBX board removes the MWAIT; 
signal (allowing the 


CPU to leave its Wait state) when it has satisfied the 
WRITE 
pulse width 
requirements. 
At this time the 


board removes the WRITE command, 
followed by the 


data, address, 
and chip select lines. This I/O WRITE 


with Wait operation 
can be seen in Figure 7. 


iSBX™ Addressing 


The iSBX boards 
are addressed 
by the host 
board 
through 
the use of the address lines MAO, MAl 
and 
MA2, and the chip se,lectlines MCSO/ and MCSI/. 
The 
host board decodes the I/O addresses and in turn gener- 
ates the chip selects for the iSBX boards. In an 8-bit sys- 
tem the host board decodes the high order 13 address 
bits and generates 
the appropriate 
chip select corre- 


sponding to those address bits. The low order three ad- 
dress bits are passed to the iSBX board via MAO-MA2. 
Thus, 
a host board 
reserves two blocks of eight I/O 
ports for each iSBX connector. There can be as many as 
three iSBX connectors "per host board, therefore a total 
of 48 addresses or six blocks of eight I/O ports that can 
be reserved for the iSBX boards. Table 2 contains a list 
of the I/O addresses and their corresponding 
host board 
iSBX port assignments 
of the iSBC 80/IOB and iSBC 
80124 host boards. 


iSBX™ Connector 
Chip Select 
iSBX™ Port 


Number 
Addresses 


iSBC 80/lOB 
MCSOI 
FO-F7 


Connector 
MCSII 
F8-FF 


iSBC 80124 First 
MCSOI 
FO-F7 


Connector 
MCSII 
F8-FF 


iSBC 80124 Second 
MCSOI 
CO-C7 
Connector 
MCSI! 
C8-CF 


Considerations 
for iSBXTMBus Interfacing 


When designing with the iSBX interface it is important 
to note that the iSBX bus is not buffered 
on the host 


board. 
Since there is no isolation 
between the iSBX 
board and the host board CPU bus, a short between sig- 
nallines 
and power or ground could have a direct effect 


on the CPU or the drivers and receivers associated with 
the CPU on the host board. 
This must be taken into 


consideration, 
especially when designing and debugging 


any custom designed iSBX MUL TIMODULE 
board. It 


is usually during the development 
states of a product 


that these types of problems occur. One advantage 
to 


not buffering 
the iSBX bus is increased speed of data 


and command transfers. 
Applications 
requiring buffer- 


ing may add the buffers on the iSBX board. A second 
advantage to not buffering is the saving of parts costs, 
board 
real estate and development 
time for the host 


board. 
Another consideration 
when designing with the 


iSBX interface is, if the application 
to be designed re- 


quires high throughput, 
like a floppy disk controller or 


a CRT controller, 
the designer may consider 
putting 


some type intelligent control of buffer RAM onto the 
iSBX board. By doing this, the transfer information 
can 


be stored in this buffer and the throughput 
of the system 


increased. 


Loading 
requirements 
for the iSBX bus have been 


broken up into two basic categories, 
output 
specifica- 


tions and input specifications, 
which can be viewed in 


Tables 3 and 4. The output 
specifications 
are the re- 
quirements on the output drivers of the iSBX board and 
are the minimum drive requirements 
necessary. A good 
example 
of this would 
be that 
the data 
bus output 
drivers must be able to sink a minimum of 1.6 mA and 
maintain 
VOL at a maximum 
of 0.5 volts and a mini- 
mum source of 200 /lA, while providing a minimum out- 
put of 2.4 volts. The input specifications 
are the re- 
quirements on the receivers of the iSBX board. An ex- 
ample of this would be that the loading of the address 
lines (MAO- MA2) can be no greater than 0.5 mA with a 
minimum low threshold of 0.8 volts. 


Optional 
Interface 
Lines 


The iSBX interface has two optional 
lines which were 


included for the user to configure the iSBX board for 
special application needs. These two lines can be used in 
a number of ways helpful in unique situations. 
For ex- 


ample, they could be used as a way to get two extra in- 
terrupt 
lines down to the host board, 
thus yielding a 


total of four interrupt 
lines running between the iSBX 


MULTIMODULE 
board 
and 
the host board. 
They 


could also be used to get extra address lines, or even 
another clock signal to the iSBX board. They could also 


Bus Signal 
Type2 
IOL Max 
@ Volts 
IOH Max 
@ Volts 
Co Min 


Name 
Drive 
- Min(mA) 
(VOL Max) 
- Min (p.A) 
(VOH Min) 
(pF) 


MDO-MD7 
TRI 
1.6 
0.5 
-200 
2.4 
130 


MINTRO-I 
TTL 
2.0 
0.5 
-100 
2.4 
40 


MDRQT 
TTL 
1.6 
0.5 
-50 
2.4 
40 


MWAITI 
TTL 
1.6 
0.5 
-50 
2.4 
40 


OPTl-2 
TTL 
1.6 
0.5 
-50 
2.4 
40 


MPSTI 
TTL 
Note 3 


Bus Signal 
Type2 
IlL Max 
@ Volts 
IIH Max 
@ Volts 
CI Max 


Name 
Receiver 
(mA) 
(VIN Max) 
(p.A) 
(VIN Min) 
(pF) 


MDO-MD7 
TRI 
-0.5 
0.4 
70 
2.4 
40 


MAO-MA2 
TTL 
-0.5 
0.4 
70 
2.4 
40 


MCSO/-MCSII 
TTL 
-4.0 
0.4 
100 
2.4 
40 


MRESET 
TTL 
-2.1 
0.4 
100 
2.4 
40 


MDACKI 
TTL 
- 1.0 
0.4 
100 
2.4 
40 


IORDI 
TTL 
-1.0 
0.4 
100 
2.4 
40 
IOWRTI 


MCLK 
TTL 
2.4 
0.4 
100 
2.4 
40 


OPTI-OPT2 
TTL 
2.0 
0.4 
100 
2.4 
40 


NOTES: 
1. Per iSBX MULTIMODULE 
board. 


2. TTL = standard 
totem-pole 
output. 
TRI = three-state. 


3. iSBX MULTIMODULE 
board 
must connect 
this signal to ground. 


be used to send a special status line to or from the iSBX 
MULTIMODULE 
board. 


iSBX™ MUL TIMODULp 
M 
DESIGN 
EXAMPLE 


This section covers the description 
of a custom iSBX 


MUL TIMODULE 
board which uses the Intel 8279 Pro- 


grammable 
Keyboard/Display 
Controller. 
This iSBX 


board, when added to an iSBC host board, provides an 
interface to a keyboard and display. A description 
of 


the hardware 
design considerations 
for breadboarding 


the hardware is presented. Following this, a software ex- 
erciser, useful for debugging the board, is described. A 
listing for the exerciser is contained in Appendix C. 


Since the iSBX MUL TIMODULE 
board was designed 


using the Intel 8279 Programmable 
Keyboard/Display 


Controller, 
a brief description of the 8279 is presented. 


The 8279 is a general purpose programmable 
keyboard 


and display I/O controller which was designed for use 
with the Intel microprocessors. 
The keyboard portion of 


this device is capable of providing a scanned interface to 
a 64-contact key matrix. It is also possible to interface to 
an array of sensors or a strobed keyboard, such as those 
of the Hall Effect or the ferrite variety. The 8279 pro- 
vides a variety of keyboard 
inputs (i.e., 2-key lockout 


and N-key rollover), and all key entries are debounced 


I 
RESET 


and strobed into an 8-character FIFO. The display por- 
tion provides the user with a scanned display interface 
for LED, incandescent, 
and other popular display tech- 


nologies. Both numeric and alphanumeric 
segment dis- 


plays may be used, as well as simple indicators. 
The 


8279 is used in this iSBX design example to provide an 
interface 
of 2-key lockout 
with key debounce 
to a 


64-character 
keyboard, 
and an interface for a 16-char- 


acter, 18-segment alphanumeric 
display. 


iSBX™ MULTIMODULE™ 
Board Design 


The iSBX board that was designed for this application 
note contains a total of three IC's, the keyboard/display 
controller, 
a flip-flop, and a 3-to-8-line decoder. Figure 


8 contains a block diagram of the hardware used in this 
design example. Figure 9 contains a schematic 
for the 


portion 
of the design example resident on the custom 
iSBX board. 


The design offers the user some flexibility as to the type 
of display or keyboard to be attached. 
For example, if 


the application 
design was defined to be for a 7-seg- 
ment, 
16-character display (as the 8279 is designed to 


drive), a 4-to-16-line 
decoder 
along with the display 


drivers could be added to the iSBX board. Another idea 
would be to include everything except the display drivers 
and the display on the iSBX board, and to put the dis- 


I 
MeSOI 
~ 
8279·5 


IORDi 
Illi 
I 
DISPLAY 
IOWRTI 
WR 
jjJ) 


AO-A3 


V5S 
BO-B3 


MPSTI 


play and drivers in with the keyboard. It is possible, and 
probably desirable in some applications, 
to incorporate 


some of the display electronics onto the iSBX MUL TI- 
MODULE board. Some of the IC's found in the display 
portion of this design could also have been placed on the 
iSBX board, 
as there is enough room on the finished 


product for doing so. 


The design was very easy to implement because, with the 
exception of one signal, all of the iSBX bus signals nec- 
essary to drive the 8279 are connected directly without 
any extra logic needed. The one signal that would not 
connect 
directly 
to the interface 
is the clock signal 


MCLK from the bus to CLK on the controller. 
It is not 
possible to connect these two together as MCLK is a 10 
MHz signal and the 8279 requires a maximum clock sig- 
nal of 3.1 MHz to generate its internal timings. It is nec- 
essary to add a 74LS74 dual D-type flip-flop to divide 
the MCLK signal by 4 for the controller. 
With this ex- 


ception, all other signals, DBO-DB7 to MDO-MD7, Ao 
to MAO, CS/ to MCSO/, etc., are connected 
directly 


to the iSBX interface. To meet the timing requirements 
of the iSBX bus, a high speed version of the 8279, the 
8279-5, is used. 


The keyboard interface side of the iSBX board consists 
of a 3-to-8-line decoder, which is used for scanning the 
keyboard matrix. The 8279 scan lines SLO-SL2 are de- 
coded by a 74LSI56 open-collector 
output decoder and 


sent to the keyboard via a connector. 


The display interface 
of the iSBX board 
consists of 
sending the scan lines and the display outputs to the dis- 
play module via a connector. 
The scan lines SLO-SL3 


are sent to the display drivers, and the display outputs 
AO-A3 and BO-B3 are sent to an ASCII to 18-segment 
decoder driver. The display is discussed in further detail 
in the next section of this application 
note. 


Display Module 
Design 


The display module design (Figure 10) consists of two 
8-digit HDSP 6805 Alphanumeric 
Displays by Hewlett 
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Packard, 
the AC5947 ASCII 
to 18-segment decoder 
driver 
by Texas 
Instruments, 
two 
Signetics 
NE590 
Peripheral 
Drivers, 
and a 74LSI22 monostable 
multi- 


vibrator. 
The display is scanned by the outputs AO-AI 


and BO-B3, which are connected 
to the inputs of the 


AC5947, and the SLO-SL3 outputs which are connected 
to the NE590 digit scanning 
circuitry. 
The interdigit 
blanking is provided by the 74LS122, which prevents a 
display ghosting type effect. With the 8279 display con- 
troller it is possible for the display to have either left 
entry, where the data enters from left to right across the 
display, overflowing in the left most display position, or 
right entry, where the data enters from the right side of 
the display and all previous data shifts left. Left entry 
was chosen for this example. The controller 
also pro- 


vides commands 
for blanking or clearing the display. 


The eight output 
lines from the decoder on the iSBX 


board select l-of-8 keyboard matrix rows for testing by 
the controller to see if a key depression has been made in 
the selected row. The keyboard matrix column output 
lines are connected 
directly to the return 
lines of the 


8279, RLO-RL7. Open-collector 
outputs 
presented 
by 


individual keys within the matrix eliminate the need for 
isolation diodes when two keys in a given column are 
depressed. The keyboard/display 
controller has the op- 


tion of using either scan keyboard, 
scan sensor matrix, 


or strobed input as modes of operation. 
With the scan 


keyboard 
mode there is a choice of using either 2-key 


lockout or N-key rollover for keyboard entry. The scan 
keyboard with 2-key lockout mode is used for this ex- 
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ample. A diagram of the keyboard interfaces and matrix 
can be seen in Figure II. 


Operation with the iSBC 80/10B™ Single 
Board Computer 


The 8279 on the iSBX expansion board is initialized to 
its mode of operation following a system reset. The key- 
board mode of operation 
is to scan the keyboard with 
2-key lockout, 
and 
the display 
mode 
is set for the 


16-character left entry mode of operation. 
Upon receiv- 


ing a character 
from the keyboard, 
the 8279 generates 


an interrupt along the M(NTRO line of the iSBX bus to 
the CPU. 
At this time the iSBC 80/lOB 
board com- 


mences I/O read operations to the iSBX board by gener- 
ating valid I/O address and chip select commands 
on 


the MAO and MCSOI 
signal lines. After the setup times 


are met, the 80/lOB 
issues an I/O read command 
by 


asserting the 10RDI line on the bus, and the base board 
reads the data from the iSBX board and removes the 
IQRD/, 
MAO, and MCSOI 
signals from the bus. After 


the data has been read in from the keyboard, 
it must be 


output to the display. The iSBC 801 lOB board starts an 
I/O write operation 
by generating a valid I/O address 


and the chip select signal with the MAO and MCSOI 
lines. After the valid setup times are met, the 10WRT 1 
line is activated by the base board. When the data has 
been valid for a minimum 
of 250 ns, the host board 


removes the 10WRTI 
line. When the hold times have 


been met, the data, address and chip select lines are also 
removed. 
Figure 
12 shows the timing 
diagrams 
just 


discussed. 
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Breadboarding 
the Design 


When doing the layout of the breadboard, 
it is also nec- 
essary to take into consideration 
the space required by 
the mounting 
holes and to plan the positioning 
of the 
components 
accordingly. (This information 
is available 
in the iSBX Bus Specification 
Manual.) 


When attaching 
the breadboarded 
design, which typi- 
cally contains 
raised wirewrap posts, it is necessary to 
raise the breadboard 
well above the host board. 
This 
can be accomplished 
by building a small cable and put- 
ting the breadboard 
on longer nylon standoffs. 
It is not 
recommended 
that the cable be longer than IS cm (6 
in.), otherwise bus timing problems could result. 


With the breadboarding 
finished it is a good idea to re- 
check all wiring connections 
for possible errors. Also 
check all signal lines with an ohmmeter between power, 
and then ground, 
for potential shorK 
An error at this 
point can cause serious damage to the host board! 


The software written for this application 
is an exerciser 
that is used for hardware 
checkout. 
It is a small pro- 
gram designed to echo characters 
from the keyboard to 
the display. The software was edited, assembled, linked 
and located with an Intel development 
system; it was 
then debugged 
with an in-circuit emulator. 
Both the 
software and the hardware debug is covered in the next 
section of this application 
note. 


To facilitate 
this discussion 
the software 
exerciser is 
divided into three sections based upon the functions per- 
formed. The three functions are: 


I) Keyboard interrupt 
routine 
2) Initialization 
and flag checking routine 
3) Character 
output routine 


A complete 
listing of the software 
exerciser can be 
found in Appendix C. 


The 8279 generates an interrupt 
to the CPU whenever 
data is introduced 
into its FIFO/Sensor 
RAM. The in- 
terrupt is cleared by doing a data read. Whenever a key 
on the keyboard is depressed an interrupt 
is generated. 
Two things are required when an interrupt occurs. First, 
the keyboard 
input data must be retrieved and stored. 
Second, the interrupt routine must indicate that there is 
some data ready to be output to the display. Therefore, 
a buffer is created in memory (called "BUFF") 
at loca- 
tion 3COOHto store the keyboard data. A data present 
flag is set in a register (REG. C) to indicate that data is 
ready to be output and can be found in the buffer. In 
this way the interrupt routine is used to input characters 
from the keyboard 
to the input buffer. 
The buffer is 
then read by the output routine, which sends the charac- 
ters to the display. 


INITIALIZATION 
AND FLAG CHECKING 
ROUTINE 


The initialization and flag checking routine first sets the 
stack pointer to the top of memory. After this the pro- 
gram proceeds to initialize the 8279 Keyboard/Display 
Controller 
to its proper mode of operation. 
The modes 
of operation 
used for this application 
note is scanned 
keyboard with 2-key lockout for the keyboard, 
and 16 
characters 
with left entry for the display. As the 8279 
has a desired internal operating 
frequency of 100kHz, 
the frequency divider chain is programmed 
to divide by 
19 hex, or 25 decimal. After the 8279 has been initial- 
ized, the program begins its next procedure 
of clearing 
the buffers. 
The keyboard 
input buffer, 
"BUFF", 
as 
well as the display buffer, "DBUFF", 
are both cleared 
to a blank display. This is done so that at the time of 
power up, the display will come up blank. 
With the 
initialization now complete, the program disables the in- 
terrupts and checks the data present flag for an indica- 
tion that data might be present for output. 
If the data 
present flag is set, the output character routine is called; 
if it is not set, the interrupts 
are enabled and the pro- 
gram loops back around to check again. In summary, 
this routine initializes the 8279 and clears the buffers, 
and then loops on the data present flag looking for an 
indication that data is present in the input buffer. The 
input buffer is a one-byte wide buffer named "BUFF." 


The character 
output 
routine 
brings the character 
in 
from "BUFF" 
(the keyboard 
input buffer) and com- 


pares it to the characters located in a table. If the char- 
acter can be matched 
to a character 
in the table it is 
replaced in "BUFF" 
with the corresponding 
character 
located in the same position of a second table. If there is 
no match, it is compared to the code for a control char- 
acter. If there is no match with a control character, 
a 
compare is made to see if the character is a delete char- 
ater. When a match is found and the acceptable charac- 
ter is placed in "BUFF", 
the output 
routine shifts the 
data in the display buffer (Figure 13) one position to the 
left and places the character 
from the input buffer into 
the display buffer at position "DBUFF" 
+ IS. Now that 


BASE 
ADDRESS 
+15 
16***81 


DBUFF 
I I 


DISPLAY 
I 
1 I 


the new information 
is in the display, the routine copies 
the complete contents of the display buffer, "DBUFF", 
to "DBUFF" 
+ 15 to the display. In the case of the in- 
put character being matched up with a delete character, 
all information 
in the display buffer is shifted to the 


right one position and the ASCII code for a blank char- 
acter is placed into the left-most position or the base ad- 
dress of "DBUFF", 
thus making the next character sent 


to the display a blank character. 
In the case of a control 


character, 
nothing is done and the program returns to 


the flag checking routine. 


Debug Considerations 


Hardware 
and software debug was accomplished 
using 


an iSBC 80/l0B 
Single Board Computer, 
an iSBC 655 


Chassis, 
an Intellec@ Series II Model 
230 Microcom- 


puter Development System, and an ICE-80™ In-Circuit 
Emulator. 


The software 
was down-loaded 
from the disk to the 


iSBC 80/IOB board using the in-circuit emulator. 
The 


ICE™ 
module 
gives the engineer 
the capability 
of 


interrogating 
the iSBC system by allowing the user to 


access and display the CPU register contents, 
status, 


system memory contents, and all I/O devices and their 
data. 


The iSBC 80/IOB board was configured to enable inter- 
rupts 
from 
the iSBX board 
via the interrupt 
0 line 


(MINTRO), which is connected to the interrupt 
pin of 


the 8080 CPU. 
The iSBX board was attached 
to the 


iSBC 80/IOB board via the iSBX connector. 
The iSBC 


80/IOB board was powered-up and the iSBX board was 


checked for proper power and ground connections. 
The 
ICE-80 emulator 
was connected 
to the iSBC 80/l0B 
board. Using the interrogation 
mode of the emulator, it 


is possible to check proper 
functioning 
of the iSBX 


board by sending and receiving data to/from 
the 8279. 


The keyboard can be tested by depressing a key on the 
keyboard and then examining the FIFO/Sensor 
RAM to 


see if the data was entered. The display RAM can alsc- 
be read and written to for testing the interface to the 
display. 


After this initial checking of the iSBX board, the soft- 
ware exerciser can then be down-loaded 
with the ICE 
module to further check the board. 


The objective of this application note is to introduce the 
reader to the iSBX MUL TIMODULE 
concept for ex- 
panding a single board computer's 
functionality, 
and to 
illustrate how a designer can use this concept with either 
standard or custom iSBX boards. In contrast to system 
expansion using MUL TIBUS-compatible 
boards, iSBX 
MULTIMODULE 
boards provide smaller, lower cost, 


incremental 
expansion. 
This application 
note explains 


how a custom 
iSBX board 
can be designed and de- 


bugged. Using this capability, it is now possible to more 
quickly add new VLSI technology 
to systems as the 
technology 
becomes available. 
Intel will continue 
to 
provide new iSBX MUL TIMODULE 
boards and, be- 
cause of the the publication 
of the iSBX Bus Specifica- 
tion and this application note, it will be easier for Intel's 
customers 
to also design and build their own custom 
iSBX boards. 


APPEN DIX A 
1-192 
APPEN DIX B 
,1·193 
APPENDIX 
C 
1·194 


APPENDIX 
A 


iSBX™ SIGNAL 
PIN ASSIGNMENTS 


Pin 
Mnemonic 
Description 
Pin 
Mnemonic 
Description 


35 
GNO 
Signal Ground 
36 
+5V 
+ 5 Volts 


33 
MOO 
MOATA 
Bit 0 
34 
MORQT 
M OMA Request 


31 
MOl 
MOATA 
Bit I 
32 
MOACKI 
M OMA Acknowledge 


29 
M02 
MOATA 
Bit 2 
30 
OPTO 
Option 0 


27 
M03 
MOATA 
Bit 3 
28 
OPT I 
Option 
I 


25 
M04 
MOATA 
Bit4 
26 
TOMA 
Terminate 
OMA 


23 
M05 
MOATA 
Bit 5 
24 
Reserved 


21 
M06 
MOATA 
Bit 6 
22 
MCSOI 
M Chip Select 0 


19 
MD7 
MOATA 
Bit 7 
20 
MCSI/ 
M Chip Select I 


17 
GNO 
Signal Ground 
18 
+5V 
+ 5 Volts 


15 
IOROI 
I/O Read Command 
16 
MWAITI 
MWait 


I3 
IOWRTI 
I/O Write Command 
14 
MINTRO 
M Interrupt 
0 


II 
MAO 
M Address 0 
12 
MINTRI 
M Interrupt 
I 


9 
MAl 
M Address 
I 
10 
Reserved 


7 
MA2 
M Address 2 
8 
MPSTI 
iSBX MULTIMOOULE 
Board Present 


5 
RESET 
Reset 
6 
MCLK 
M Clock 


3 
GNO 
Signal Ground 
4 
+5V 
+5 Volts 


I 
+ 12V 
+ 12 Volts 
2 
- 12V 
- 12 Volts 


APPENDIX 
B 


iSBX™ MUL TIMODULp 
M 
BOARD I/O AC SPECIFICATIONS 


Symbol" 
Parameter 
Min(ns) 
Max (ns) 


tl 
Address 
stable 
before 
read 
50 
- 


t2 
Address 
stable 
after 
read 
30 
- 


t3 
Read 
pulse 
width 
300 
- 


tpl 
Data 
valid 
from 
read 
0 
250 


tpl 
Data 
float 
after 
read 
0 
150 


t6 
Time 
between 
RD 
and/or 
WRT 
- 
Note 
3 


t7 
CS stable 
before 
CMD 
25 
- 


ts 
CS stable 
after 
CMD 
30 
- 


t9 
Power 
up reset 
pulse 
width 
50 ms 
- 


tlO 
Address 
stable 
before 
WRT 
50 
- 


tll 
Address 
stable 
after 
WRT 
30 
- 


tI2(2) 
Write 
pulse 
width 
300 
- 


tl3(2) 
Data 
valid 
to write 
250 
- 


tl4 
Data 
valid 
after 
write 
30 
- 


tIS 
MCLK 
cycle 
100 
110 


tl6 
MCLK 
width 
35 
65 


t17(I) 
MW AIT / pulse 
width 
0 
4 ms 


tIS 
Reset 
pulse 
width 
50 ms 
- 


tl9 
MCS/ 
to MWAIT/ 
valid 
0 
75 


t20 
DACK 
set up to I/O CMD 
100 
- 


t21 
DACK 
hold 
30 
- 


t22 
CMD 
to DMA 
RQT 
removed 
to end 
of DMA 
cycle 
- 
200 


t23 
TDMA 
pulse 
width 
500 
- 


t24(1) 
MW AlT / to valid 
read 
data 
- 
0 


t25(1) 
MWAIT/ 
to WRT 
CMD 
0 
- 


NOTES: 
I. 
Required 
only if WAlT 
is activated. 


2. If MWAITI not activated. 
3. To be specified 
by each iSBX MUL TlMODULE 
board. 


• 
For a more complete 
definition 
of symbols 
refer to iSBX Bus Specification, 
142686-001. 


APPENDIX 
C 


LISTING 
FOR THE iSBX™ DESIGN 
EXAMPLE SOFTWARE 
EXERCISER 


0040 
0060 
0070 


003B 
31Fr3F 


003E 
3E08 


0040 
D3Fl 


0042 
3E39 


OOH 
D3F1 
0046 
3E08 


0048 
03FI 


004,\ 
OEEO 
004C 
21003C 


004F 
71 
0050 
OhOF' 


0052 
210FlD 


0055 
71 


0056 
2B 


0057 
05 


0058 
C25500 


005B 
Fl 


005C 
AF 


0050 
B9 
OOSE 
CA6400 
0061 
CD6800 
0064 
FB 


0065 
C35BOO 


1 
; •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 


2 I' 
• 


3 
I' 
THIS 
PROGRAM 
VAS 
USED 
AS 
U 
EXAMPLE 
FOR 
EXERCiSiNG 
THE 
• 
4 
I' 
8279 
ISBX 
MULTI 
MODULE 
BUILT 
FOR 
THIS 
APPLICATION 
NOTE. 
• 


5 
;' 
• 


6 
, •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 


7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
11 
32 
33 
34 
35 
36 
37 
38 
39 
40 
U 
42 
U 
H 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 


; 
. 


: 
PROGRAM 
EOUATES 
, 
. 


; 
POPT 
ADDRESS 
TO 
READ 
OR 
WRITE 


I/DATA 
TO/OR 
FROM 
KEYBOARD/DISPLAY 


I 
PORT 
ADDRESS 
TO 
SEND 
COMMANDS 


I/TO 
KEYBOARD/DISPLAY 


I 
CONTROL 
CHAR. 
TO 
SET 


I/KEYBOARD/DISPLAY 
MODE 
FOR 


:/12 
KEY 
LOCKOUT.16 
CHAR 
LEFT 
ENTRY 


I 
CONTROL 
CHAR. 
TO 
SET 
8279 
CLK 


I/To 
100 
KHz 
INTERNAL 
TIMING 


1 
CONTROL 
CHAR. 
TO 
READ 
KEYBOARD 


1 
CONTROL 
CHAR. 
TO 
READ 
DISPLAY 
RAM 
: 
CONTROL 
CHAR. 
TO 
READ 
DISPLAY 
RAM 
/llUTO 
INCREMENT 


1 
CONTL 
CHAR. 
TO 
WRITE 
TO 
DISPLAY 
RAM 
: 
CONTL 
CHAR. 
TO 
WRITE 
TO 
DISPLAY 


/lRAM 
lUTO 
INCREMENT 
1 
CONTROL 
CHAR. 
TO 
CLEAR 
OR 
BLlNK 
/lDISPLAY 
1 
ADDRESS 
OF 
KEYBOARD 
INPUT 
BUFFER 


1 
ADDRESS 
OF 
DISPLAY 
BUFfER 


ROFIFO 


RDRAM 
RORANA 


; 
, 
, 
. 


1 
INITIALIZE 
PROGRAM 
1 
AND 
KEY 
SOARD 
OISPLlY 
CONTROLLER 


SP,3FFFH 
A,/IIOoEO 


CHOAO 
A ,PROGCK 
CHOAO 
A,CLP 
CHOlO 
C,OEOH 
H,BUFF 
H.C 
B,Ot'H 
H,DBUFF+OFH 
M.C 
H 
B 
ZDBUFF 


INITIALIZE 
STACK 
PT 
GET 
CONTROL 
CHAR. 
SET 
KEYBOARD/DISPLAY 
MODE 


GET 
CONTROL 
CHAR. 
SET 
8279 
CLK 
FOR 
100 
KHz 
GET 
CONTROL 
CHAR. 
CLEAR 
OR 
BLANK 
OISPLlY 


SET 
POINTER 
TO 
INPUT 
BUfFER 


CLEAR 
INPUT 
BUFFER 
to 
BLANt( 


SET 
COUNTER 
= 
IS 
; 
St:T 
POINTER 
TO 
DBUFf 
+15 


: CLEAR 
DISPLAY 
BurrER 
TO 
:/DI"PLAY 
BUFFER 
.15 
TO 
CODE 


;/rOR 
CLEARING 
OR 
BLANKING 
OUT 


; ITHE 
01 SPLAY 


; 
. 


THIS 
IS 
THE 
BACKGROUND 
PROGRAM 
WHICH 
LOOPS 
CHECKING 
FOR 
THE 
OATl 
PRESENT 
FLAG 


A 
C 
LABEL 
OUTPT 


1 
DISABLE 
INTERRUPTS 
; ICLEAR 
A 
REG 
AND 
CO~PARE 
WITH 


IIC 
REG 
CHECKING 
FOR 
DATA 
PRESENT 


III, 
PRES!;NT 
CALL 
OUTPT 
;/To 
DISPLAY 
CHAR. 
I/IF 
NO 
DATA 
PRESENT 
ENABLE 


: IINTERRUPTS 
AND 
JflIP 
BACK 


OObB 
3A003C 
006B 
062B 


0060 
21DEOO 
0010 
110901 
0013 
BE 
0014 
CASOOO 


0011 
05 
001B 
CAC600 


001B 
23 
001C 
13 


0010 
C31300 
OOBO £B 
OOBI 
1E 
0082 
21003C 
00B5 
11 
0086 
060r 


0088 
110030 
OOBB 
210130 
008E 
1E 
OOBr 
23 


0090 
EB 


0091 
11 
0092 
23 
0093 
E8 
0094 
05 
0095 
C2BEOO 
0098 
3A003C 
009B 
320nD 
009E 
0610 
OOAO 210030 
00A3 
1E 


00A4 
D3ro 
00A6 
23 
DOH 
05 


OOAS C2AlOO 
OOAB OEOO 
OOAD C9 


OOAE 060r 
OOBO 1I0nD 
00B3 
210E3D 


0086 
1E 


00B1 
2B 
00B8 
EB 


00B9 
11 


008" 28 
OOBB E8 
OOBC 05 
OOBO C2B600 
OOCO EB 
OOCI 
36EO 
00C3 
CHEOO 


00C6 
rErA 
OOCB CAlBOO 
OOCB rEr9 
OOCD CUEOO 
0000 
C9 


0001 
3E40 


0003 
D3F! 


0005 
DBro 


0001 
21003C 
OODA 11 
OODB OErr 
0000 
C9 


LOA 
"VI 
LXI 
LXI 
C"P 
JZ 
OCR 
JZ 
INX 
INX 
J"P 
XCHG 
"OV 
LXI 
"OV 
"VI 
LXI 
LXI 
"OV 
INX 
XCHG 
"OV 
INX 
XCHG 
OCR 
B 
I 
TEST 
Ir 
DONE 
JNZ 
LOOPI 
'lAND 
GO BACK 
Ir 
NOT 
LOA 
Burr 
,/ELSE 
READ 
KEYBOARD 
DATA 
STA 
DBurr_orH 
llANO 
PLACE 
IT 
IN 
THE 
DBurr 
MVI 
B,10H 
J 
SET 
COUNTE~ = 
16 
LXI 
H,DBurr 
I 
SET 
POINTER 
z DBurr 
1ST 
POS. 


MOV 
A,fII 
:/REAO 
1 
BYTE 
FROM 
DBUY,. 


OUT 
DATAAD 
llANO 
SENT 
IT 
TO 
DISPLAY 
ItiX 
H 
1 
UPDATE 
POINTER 
OCR 
B 
llANO 
TEST 
Ir 
DONE 
JNZ 
LOOP2 
I/GO 
BACK 
Ir 
NOT 
DONE 
"VI 
C,OH 
IIELSE 
CLR 
DATA PRESENT 
FLAG 


RET 
;/AND 
RETURN 
; 
. 


CHARACTrR 
DFLETE 
OR 
RUB OUT 


Burr 
8,28H 
H,TABLE! 
D,TABLE2 
"UTCH 
B 
CONTROL 
H 
o 
COMPARE 


A, 
M 
H, BUFf 
M,A 
B,orH 
O,DBUfF 
H,08UFF+l 
A,M 
H 


MVI 
LXI 
LXI 
"OV 
OCX 
XCHG 
MOV 
DCX 
XCHG 
OCR 
JNZ 
XCHG 
MVI 
JMP 


B,orH 
D,DBUff' 
.•.OFH 
H, DBUfF 
.•.OEH 
A,M 
H 


; 
. 
I 
CHECK 
Ir 
CHARACTER 
IS 
CONTROL 
OR DELETE 
CHARACTER 


orAH 
BEGIN 
or9H 
DELETE 


LOAD 
A wITH 
KEYBOARD 
DATA 
SET 
COUNTER 
MAX POSSIBLE 
CHAR. 


SET 
POINTER 
TO 
INPUT 
TABLE 
SET 
POINTER 
TO 
OOTPUT 
TABLE 


I 
COMPARE 
KEYBD 
DATA TO 
INPUT 
I/TABLE 
Ir 
= 
JMP 
TO 
MATCH 
I/ELSE 
DECREMENT 
COUNTER 
Ir 
0 


I/JMP 
TO 
CONTROL 
I/ELSE 
INCREMENT 
BOTH 
TABL£ 
I/POINTERS 
AND JMP 
TO COMPARE 


SET 
COUNTER 
= 
TO 
15 
POINTER 
TO 
rIRST 
LaC 
IN 
DBorr 


POINTER 
TO 
2ND 
LaC 
IN 
DBurr 


I 
READ 
HIGH 
POINTER 
rROM 
DBorr 
I/UPDATE 
HIGH 
POINTER 


I 
SET 
COUNTER 
=15 
SET 
POINTER 
= 
DBurr_15 
I 
SET 
POINTER 
= 
DBurr_14 
I 
READ 
LOW POINTER 
rROM 
DBurr 
I/UPDATE 
LOw 
POINTER 


TEST 
Ir 
DONE 
;/ANO 
CO 
BACK 
If 
NOT 
I/ELSE 
SET 
DBurr 
rOR 
IICODE 
TO 
BLANK 
DISPLAY 
llANO 
JMP 
TO 
LOOPA 


I 
CO"PARE 
rOR 
CONTROL 
CHAR. 
I/Ir 
CONTROL 
J"P 
TO 
BEGIN 


I/ELSE 
CaMP. 
rOR 
DELETE 
CHAR, 


I/Ir 
DELETE 
J"P 
TO 
DELETE 
;/ELSE 
RETURN 


; 
. 


KEYBOARD 
INPUT 
INTERRUPT 
ROUTINE 


A,RDFIfO 
CIIlDAD 
DATAAD 
H,BurF 
",A 
c,orFH 


GET 
CONTL 
CHAR. 
TO 
READ 
rlro 
SET 
8219 
rOR 
READ 
NODE 


READ 
KEYBOARD 
DATA 
IN 
I 
SET 
POINTER 
TO 
Burr 


llANO 
STORE 
KEYBOARD 
DATA 


IITHEN 
SET 
DATA PRESENT 
rLAG 
II AND RETURN 


158 
1 ••••••••••••• 
, ••••••••••••••••••• 
*' ••••••• 
f •••••••••• 
, ••••••••••••••••••••••••• 


159 
I 
TABLE 
I 


160 
ACCEPTABLE 
INPUT 
CHARACTERS 
FRON 
KEY80ARO 


161 
I 


OOOE 
DE 
162 
TABLEI: 
08 
ooEH ,OfFH, 
GErH, DEEH, O~5H 
,OF6H, 
OFEH ,DebH 


DO OF 
FF 
ODED 
EF 
ODE I 
EE 
00E2 
E5 
00E3 
F6 
00E4 
FE 
ODES 
C6 
00E6 
C9 
163 
08 
OC9H, OCAHI 002H, 
OoA", 003H, 
OC7H, 001H, 
009H 


00E1 
CA 
00£8 
02 
00E9 
OA 
OOEA 
03 
00E8 
C1 
OOEC 
01 
ODED 
09 


OOEE 
05 
164 
DB 
ODSH, OEDH, OE6H, OF'SH, DC1H, OF7H, 
oooH, DE7H 


OOEF 
ED 
OOFO 
E6 
DOn 
F5 
Don 
CI 
Don 
n 
00F4 
DO 
00F5 
E1 


00F6 
FO 
165 
08 
orOH, 
oorH, 
OCCH, 
004H, 
ODCH, 
OE4H, 
DECH, 
OF4H 


Don 
OF 
OOFB 
CC 
00F9 
04 
Don 
DC 
OOFB 
E4 
OOFC 
EC 
OOFO 
F4 
DarE 
FC 
166 
DB 
OfCH, oeOH, oC8H, OooH, 098H, 
0"2H, 
ocrH, 
OAAH 


DOFF 
CO 
0100 
cB 
0101 
DO 


0102 
9B 
0103 
A2 
0104 
CF 
0105 
AA 
0106 
E8 
161 
08 
DEBH, 
DElH, 
o08H 


0101 
E3 
OIOB 
DB 
16B 


169 
;.............................................................................. 
170 
I 
TABLE 
2 


171 
ACCEPTABLE 
OUTPUT 
CHAHACTERS 
TO DISPLAY 
172 
I 


0109 
CI 
173 
TABLE2 : 
DB 
oCl H, OC2H, oC3H, oC4H, oe5H, 
OC6H, oC7H, OCBH 


OIOA 
C2 


OIOB 
C3 
OIOC 
C4 
0100 
C5 


OIOE 
C6 


OIOF 
Cl 
0110 
C8 


0111 
C9 
114 
08 
OC9H, aCAH, DCBH, oeCH, oeDH, OCEH, GerM, oooH 
0112 
CA 
0113 
CB 
0114 
CC 
0115 
CO 
0116 
CE 


0117 
CF 
0118 
00 
0119 
01 
175 
DB 
001 H, 002H, 
003H, 
004H, 
005H, 
006H, 
o07H, 
o08H 


011A 
02 
OIIB 
03 
OIIC 
04 


0110 
05 


OIlE 
06 


OIlF 
07 


0120 
08 
0121 
09 
176 
DB 
009H, 
ODAH, Of1 H, 0f'2H, 
Of]ti, 
or4H, 
OFSH, 
OF6H 


0122 
OA 


0123 
F! 


0124 
F2 
0125 
F3 
0126 
F4 


0127 
F5 


0128 
F6 


0129 
F1 
171 
DB 
or7H, 
oreH, 
OrgH, 
orOH, 
orOH, 
OEBH, 
OEOH, 
DEAH 


ola 
F8 
012B 
F9 
012C 
FO 
0120 
FO 


012E 
EB 


012F 
EO 
0130 
EA 
0131 
EF 
178 
DB 
OEFH,OEEH,02DH 
0132 
EE 
0133 
20 
0000 
179 
END 
START 


PUBLIC 
SYMBOLS 


EXTERNAL 
SYMBOLS 


USER SYMBOLS 
BEGIN 
A 003B 
BUFF 
3COO 
CKFLAG 
005B 
CLR 
A 0008 
(MOAD 
OOF! 
COMPAR 
0073 
CONTRO 
A 00C6 
DATA AD 
A Dora 
OBun' 
3000 
DELETE 
OOAE 
INT 
A 0001 
LABEL 
0064 
LOOPI 
008E 
LOOP2 
A 00A3 


LOOPA 
A 009E 
LDOPB 
00B6 
HATCH 
0080 
MOOED 
A 0008 
OUTPT 
0068 
PROGCK 
0039 
ROFIFO 
A 0040 
HDRAM 
A 0060 
RORAMA 
0070 
START 
0000 
TABLEI 
A OOOt 
TABLE2 
0109 
WRRAM 
0080 
WRRAMA A 0090 


ZOBUFF 
A 0055 


ASSEMBLY 
COMPLETE, 
NO ERRORS 


gill Part 
11 


Reduce your ,uC-based system design time 
by using single-board microcomputers. 
Assembled boards 
in the SBC-80 series offer stock answers to custom demands. 


System 
designers 
eager to take advantage 
of the 
dramatically 
increased 
capabilities 
of 
micro- 


computers 
have been hindered 
two ways: Their pro- 


duction volumes have been too low to amortize soft- 
ware and hardware 
development 
costs effectively, or 


hardware 
subtleties 
and test requirements 
have con- 


fined them to fully assembled 
and tested computer 


subsystems. 
But now those obstacles 
are overcome 


with families 
of fully assembled 
and tested 
micro- 


computers 
and system-expansion 
boards like the Intel 


SBC-80 series. 
They are ready-to-use, 
flexible and 


inexpensive-prices 
range from just $195 to $825 in 


unit 
quantities. 
The main members 
of the SBC-80 family are the 


80/04, 
80/05, 
80/l0A, 
80/20 
and 
80/20-4 
central- 


processor boards, with either an 8080A or 8085 micro- 
processor 
acting as the master 
CPU (Table 1). Most 


of the boards measure 
6.75 X 12 in. and contain the 


CPU, clock, read/write 
memory, 
control ROM, I/O 


ports, serial communications 
interface 
and bus-con- 


trol logic. 


I/O interfacing 
is an area where design flexibility 
is essential to meet changing requirements 
efficiently. 
The programmable 
parallel and serial I/O structures 
of the boards make them versatile 
enough to do just 


that. What's more, upgrading 
system performance 
is 


easy thanks 
to the SBC-80 system bus, the Multibus, 
which permits 
modular 
performance 
expansion. 
The Multibus provides a defined, standard 
interface 
between the SBC-80 single-board 
computers 
and ex- 
pansion boards. As many as 16 SBC-80 family boards 
can simultaneously 
share the bus. 


All in the SBC·SO family 


As 
exemplified 
by 
the 
block 
diagram 
of 
the 
SBC-80/lOA (Fig. 1), the SBC-80 microcomputer 
sys- 


tem has all that's 
needed for many applications. 
The 


SBC-80/lOA is the oldest board in the family and has 
been widely imitated 
since it was one of the first 


"standardized" 
microcomputers 
commercially 
avail- 


able. 


The CPU section of the 80/l0A 
board consists 
of 


George 
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the 8080A CPU, the 8224 clock generator 
and the 8238 


system controller. 
Capable of fetching and executing 


any of the 8080A's 78 instructions, 
the CPU section 
can respond to interrupt 
requests 
originating 
on and 


off the board. (For more about the 8080A, see "Micro- 
processor 
Basics, Part 2," ED No. 10, May 10, 1976, 


p.84). 


The system-bus 
interface section includes an assort- 


ment of circuits 
to gate the interrupt 
and hold re- 


quests, the ready signals, and a system-reset 
signal. 


Other 
circuits 
drive the various 
control 
lines. Two 


8216s help drive the bidirectional 
data bus, and six 


8226s drive 
the external 
system-data 
and address 


buses as part of the SBC-80/lOA's Multibus interface. 


The RAM section of the 80/l0A 
consists 
of 1024 


bytes of static 
MOS memory. 
For program 
storage, 


up to 8192 bytes of ROM can be mounted on the board 
in 1024-byte increments 
by means of a 2708 or 8708 


EPROM, an 8308 mask-programmed 
ROM, or in 2048 


bvte increments 
via the 2716 EPROM or 2316 ROM. 


. A serial 
interface 
on the board uses an 8251 pro- 


grammable 
universal 
synchronous/asynchronous 


receiver/transmitter 
to provide a serial-data 
channel. 


The serial port operates at programmable 
rates up to 
38,400 baud (synchronously) 
or 19,200 baud (asynchro- 


nously) with a choice of character 
length, number of 


stop 
bits, 
and 
even, 
odd or no parity. 
On-board 


interfaces provide direct EIA RS-232 or teletypewriter 
current-loop 
compatibility. 
Two 
8255 
programmable 
peripheral 
interface 


circuits 
provide 48 I/O lines for transferring 
data to 


or from peripheral 
devices. Eight already-committed 


lines 
have 
bidirectional 
drivers 
and 
termination 


networks 
permanently 
installed, 
so that they can be 


inputs, 
outputs 
or bidirectional 
(jumper-selectable): 


The other 40 lines are uncommitted. 
On-board sockets 


permit 
drivers 
and termination 
networks 
to be in- 


stalled, as needed. Since software 
configures 
the I/O 


lines, I/O can be customized 
for every application. 


The 80/lOA also responds to a single-level interrupt 


that 
can originate 
from 
one of many 
sources, 
the 


USART, programmable 
I/O and two user-designated 


interrupt-request 
lines. When an interrupt 
is recog- 


nized, a Restart-7 
instruction 
is generated, 
and the 


processor 
accesses 
location 
38H to get the starting 


address 
of the service routine. 


System expansion 
and support 
are possible with a 


wide vilriety 
of alternate-source 
CPU, memory, 
and 


I/O boards (Tables 2 and 3). Up to 65,536 bytes of ROM, 
PROM 
or 
RAM 
can 
be accessed 
by one 80/lOA. 
Expandable 
backplanes 
and card cages are also avail- 


able to support 
multiboard 
systems. 


Interfacing starts with the bus 


Although 
the 
SHC-80/10A 
is a complete 
micro- 


computer 
system, 
it can be expanded 
readily or it can 


serve as a primary 
master 
controller 
for other micro- 


computer 
cards. The 80/l0A 
has five edge connectors, 
three on the top of the board and two on the backplane, 
or bottom, 
side. Two of the "top" connectors, 
J1 and 


J2, serve as parallel 
I/O ports, while J3 is a serial I/O 


RS 232C 
COMPATIBLE 
DEVICE 
DB SERIAL 


DATA 
INTER· 
FACE 


ADDRESS 
BUS 


DATA 
BUS 


CONTROL 
BUS 


port. All parallel 
I/O lines on the 50-contact J, and 


J2 connector 
areas 
are paired 
with 
an independent 


signal/ground 
pin to permit 
alternate 
signal/ground 


wiring when using flat-cable interconnects. 
Serial port 


J3 uses 
a 26-contact 
PC-edge 
connector 
to provide 


interfaces 
for both RS-232 and current-loop 
devices. 


To 
communicate 
with 
other 
system-compatible 


boards, 
the 80/10A uses the 86-pin Multibus 
(PI). To 


provide accessible 
test points, 
the 80/l0A 
has a 60- 
pin edge connector 
(P2). 
The control 
signals 
on the 


Multibus 
provide 
the real 
power 
and capability 
in 
control 
applications. 
Of the 86 pins that 
make up the Multibus, 
24 are 
assigned to power and ground, 
16 to addressing, 
eight 


to bidirectional 
data, 
and 
12 to signal 
and control 


1 
INTERRUPT 
REOUEST 
LINE 


USER 
DESIGNATED 
PERIPHERALS 
D 
U'48PROGRAMMABLE 
PARALLEL 
I/O LINES 


2 INTERRUPT 
REOUEST 
LINES 


1. Based on an 8080A /lP, the 80/10A microcomputer has 
a straightforward 
design suitable for general-purpose 
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P2 


computing and control. The board has 48 programmable 
I/O lines and serial interfaces. 


COMMON 
HIGH 
SPEED 
MATH 


PROCESSOR 


(SeC 
310) 


2. The Multibus interface for the sac·so CPU boards not 
only permits 
simultaneous 
multiprocessing, 
but also 
enables several processors 
to share the same bus and 


(these 
12 are defined 
in Table 4). The remaining 
26 


pins are unassigned 
at this point. Higher 
capability 
SBC-80 products, 
though, 
are in development. 
These 


boards 
will use many of the unassigned 
lines (eight 


unassigned 
pins are allocated 
for additional 
bidirec- 


tional data lines). The remaining 
lines provide multi- 


level (eight) interrupt 
lines, various control lines and 


a multi master, 
bus-arbitration 
control structure 
(Fig. 


2). Address 
and data 
lines are three-state, 
and the 


interrupt 
and control 
lines are open-collector. 


Boards 
using 
the 
Multibus 
have 
a master-slave 
relationship: 
A bus master-such 
as an SBC 80 CPU 


board, a DMA controller 
or a diskette 
controller-can 


control 
the command 
and address 
lines. Conversely, 


slave boards-such 
as a memory, 
I/O-expansion 
or 


mathematics 
boards-cannot 
control 
the bus. 


Arbitration 
resolves 
priority 
disputes 


In multimaster 
systems, 
the bus-arbitration 
logic 


uses the CCLK signal of the bus to provide a timing 
reference 
to help satisfy 
many simultaneous 
requests 
for bus control. 
As a result, 
different 
speed masters 


peripheral devices. Arbitration logic on the CPU boards 
decides which board gets on the bus first if several units 
simultaneously 
access the bus. 


can share 
resources 
on one bus. Actual 
transfers 
on 


the bus proceed asynchronously 
with respect 
to the 


bus 
clock. 
Once 
bus 
access 
is granted, 
single 
or 


multiple 
read/write 
transfers 
can proceed at up to 150 


kbytes/s 
for CPU operations 
and up to 1 Mbyte/s 
for 
DMA operations. 
The 
bus 
has 
a bandwidth 
of 5 


Mbytes/s 
so that 
future 
performance 
enhancements 


may be directly 
supported. 


Both serial and parallel 
modes of bus-priority 
reso- 


lution are available. 
In the serial 
mode, up to three 


masters 
can 
share 
the 
system 
bus, 
with 
requests 
ordered 
on the basis of bus location. Each master 
on 
the bus notifies 
the next one down in priority 
when 
it needs to use the bus, and monitors 
the bus-request 
status 
of the closest higher-priority 
master. 
With an 


external 
priority 
network, 
up to 16 masters 
can share 
the bus. 


The dual-bus 
nature 
of the Multibus 
permits 
each 
processor-based 
master 
within 
the system 
to retain 
its own local memory and I/O, which it uses for most 
operations. 
Such local operations 
occur entirely on the 


individual 
board 
and don't 
require 
the system 
bus. 
In contrast 
to the dual bus architecture, 
all masters 


Table 1. Comparison of SBC-80 CPUs 


SSC 80/04 
SSC 80/05 
SSC 80/l0A 
SSC 80/20 
SSC 80120-4 


CPU 
8085 
8085 
8080A 
8080A 
8080A 
EPROMcapacity (bytes) 


(with 2716) 
4096 
4096 
8192 
8192 
8192 


(with 2708) 
2048 
2048 
4096 
4096 
4096 
RAM (bytes) 
256 
512 
1024 
2048 
4096 
Programmable 
parallel 
I/O lines 
22 
22 
48 
48 
48 
Serial I/O capability 
RS232C 
RS232C 
RS232C/TTY 
RS232C2 
RS232C2 


SID/SODI. 2 
SID/SODI. 2 
USART 
USART 
USART 


Timers 
1 
1 
0 
2 
2 
Interrupt 
levels 
4 
4 
1 
8 
8 
Multibus interface 
None 
Multi-master 
Single-master 
Multi-master 
Multi-master 
Price (unit quantity) 
$195 
$350 
$495 
$735 
$825 
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SSC 016 
SSC 032 
SSC 048 
SSC 064 
SSC 094· 


Combina- 
SSC 104 


tion 
memory 
and I/O 


16 kbyte dynamic RAM 
32 kbyte dynamic RAM 
48 kbyte dynamic RAM 
64 kbyte dynamic RAM 
4 kbyte CMOS static 
RAM with 96 hour bat- 
tery backup. 
16 kbytes using 2708 
tyoe (1024 x 8) EPROM 
32 input 
lines/32 
out- 
put 
lines. 
all 
buf- 


fered/terminated 


Price 
(unit 
qty) 
$ 825 
$1360 
$1860 
$2200 
$ 795 


$ 295 


$ 350 


48 programmable 
par- 
$ 400 
allel 
lines 
with 
full 
bufferi ng/termi nation 
options. 
full 
RS232C 
port. 
1 ms 
real-time 
clock. and 8-line inter- 
rupt 
control 


72 programmable 
par- 
$ 395 
allel 
Imes 
with 
full 
bufferi ng/termi nation 
options. 
real-time 
clock 
(interval 
is 
jumper 
selectable 
to 
0.5. 1. 2. or 4 ms). and 
8-level programmable 
interrupt 
control. 


Four 
programmable 
$ 650 
synch 
ro no u s/asyn- 
chronous 
serial ports. 
each 
with: 
program- 
mable baud rates. pro- 
grammable 
data 
for- 
mats. 
programmable 
interrupt 
contrOl. 
16 
RS232C buffered 
pro- 
grammable 
parallel 
I/O lines configured 
as 
a Sell Model 801 auto- 
matic 
calling 
unit 
in- 


terface. Two program- 
mable 
16-bit 
interval 
timers (usable as real- 
time clocks). and soft- 
ware 
selectable 
loop- 
back of serial ports for 
diagnostic 
use. 


48 
optically 
isolated 
$ 395 
lines; 24 input 
16 out- 


put. 
and 
8 program- 
mable (in/out). 
8-level 
programmable 
inter- 


rupt control. and 1 ms 
real-time 
clock. 


16/8 
(single-ended/ 
$ 895 
differential) 
12-bit aid 
channels; 
user expan- 
dable 
on-board 
to 
32/16 channels 


Combination 
analog 
$1125 
I/O; same aid capabili- 
ty as SSC 711 plus 2 
d/a channels 
8 
kbytes 
capacity 
$ 715 
(sockets) 
using 
2716 
(2 k x 8) EPROM or 4 
k using 2708. 4 kbytes 
dynamic 
RAM. 48 pro- 
grammable 
parallel 
I/O lines. with full buf- 
fering/termination. 
as 
options. RS-232C port. 
alms 
real-time clock. 
and an eight-line inter- 
rupt control 


·Requlres 
+ 5 V only. 
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in multimaster/single-bus 
systems 
use the common 
bus for all instructIOn 
or data 
fetches 
or whenever 
data 
must 
be written 
to output 
devices or memory. 


Rapidly, then, the system bus becomes the bottleneck 
for over-all 
system 
throughput. 
Masters 
in SHC-80 
systems 
only use the Multibus 
when data or instruc- 
tions are resident 
in common, 
or global, memory 
or 
I/O. Since masters 
can request 
the Multibus 
simulta- 
neously, on-board arbritration 
logic resolves any mul- 
tiple contention. 


Examine board performance 


A look 
at 
the 
entire 
family 
of SHC-80 
micro- 
computers 
reveals 
varied 
levels of performance. 
All 
five boards are inexpensive, 
but the most inexpensive 
is the 80/04, which costs $99 in 100-unit quantities, 
and is intended 
for stand-alone 
applications. 
To get 
the cost down, the board was designed to use the 8085 
CPU and thj! 8155 RAM, timer 
and I/O circuit. 


The 80/04 contains 
an 8085 CPU, 256 bytes of RAM, 
space for up to 4 kbytes of EPROM (two 2716 EPROMs, 
or two 2708 EPROMs), 22 programmable 
parallel 
I/O 


lines with sockets for buffer and termination 
options, 


a 14-bit programmable 
timer/event 
counter, 
and pro- 


vision 
for an RS-232-C 
serial 
port 
using 
the 
8085 
SID/SOD 
serial 
interface. 
The board can also house 
an on-board +5- V regulator, 
so an unregulated 
voltage 
can be connected. 


The next step up, the 80/05, has the same architec- 
ture 
and connector 
types 
and pinouts 
as the 80/04. 


Direct 
software 
compatibility 
is achieved 
with 
the 
same CPU along with the same RAM, ROM, I/O, and 
timer addressing. 
However, 
the 80/05 contains 
twice 
as much RAM as the 80/04. And since the 80/05 has 
the full Multibus 
multimaster 
interface, 
80/05-based 
systems 
can be expanded 
with any of the Multibus- 
compatible 
boards 
from 
Intel 
or other 
suppliers. 


The SHC-80/10A 
comes next. It provides 
more on- 
board 
memory 
and 
I/O 
for systems 
requiring 
ex- 
panded on-board 
resources. 
Hased on the 8080A CPU, 


the board contains 
1 kbyte 
of RAM, up to 8 kbytes 


of EPROM/ROM, 
48 programmable 
parallel I/O lines, 


a full USART 
serial 
port 
with 
RS-232-C and 
tele- 


Same as SSC 104. ex- 
$ 815 


cept 
has 8 kbytes 
of 
dynamic 
RAM 


Same as SSC 104. ex- 
$ 985 


cept has 16 kbytes of 
dynamic 
RAM 
High speed mathema- 
$ 595 


tics 
processor 
includ- 


ing 
floating-point 
ca- 
pability 
(32 bit). 


Dual single-density dis- 
$ 995 


kette controller 


Quad 
double-density 
$1290 


diskette 
controller 


DMA controller. 
up to 
$ 450 


1 MHz transfer 
rates 


SSC 202 


DMA 
SSC 501 
control 


typewriter 
interfaces, 
and a full Multibus 
interface 
(but only single-master 
capability; 
the board has no 
multimaster 
capability). 
Intended 
for single"CPU sys- 
tems 
with 
only one other 
Multibus 
peripheral 
con- 
troller, 
the 80/10A 
can interface 
with 
such 
as the 
SBC-201 or SBC-202 single 
and double-density 
dis- 
kette 
controllers, 
or the SBC-501 DMA controller. 


System 
designers 
requiring 
the same on-board 
I/O 


capability 
as the SBC-80/10A 
but with more RAM, 
more efficient 
real-time 
capability, 
and full multi- 
master 
Multibus control can go further 
up the ladder 


to the SBC-80/20 or SBC-80/20-4. These boards differ 
only in that the 80/20 contains 
2 kbytes of RAM and 
the 80/20-4 contains 
4 kbytes. 
Both boards .can hold 
up to 8192 bytes of ROM or EPROM, handle up 
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3. Programmable 
I/O 
lines from 
the sac·so parallel 
interlaces can be set so that they are individually program- 
mable as inputs or outputs (a). byte-programmable as 
inputs or outputs with handshaking (b). or bidirectional 
on a byte-programmable 
basis (c). 


to eight levels of prioritized 
interrupt, 
and share the 
Multibus 
in the multimaster 
mode. Either 
board has 


two programmable 
interval 
timers/event 
counters. 


Auxiliary 
power 
buses 
and memory-protect 
control 
logic on the board permit 
battery 
backup of the RAM. 


Take advantage of interrupts and timers 


Real-time applications 
frequently 
require that high- 


priority 
programs 
operate 
on the basis 
of external 
events, time-of-day, 
or elapsed time without 
impact- 
ing 
current 
background 
processing. 
These 
multi- 


programming 
requirements 
are 
supported 
in 
the 


80120 
and 80/20-4 
by an eight-level 
programmable 


interrupt 
controller 
(PIC) 
and 
two 
programmable 


interval 
timer/event 
counters. 
The priority 
level of 
any event generating 
an interrupt 
request 
is assigned 


through 
jumper 
selection 
and the priority 
algorithm 


chosen 
by system 
software. 
Any combination 
of interrupt 
levels may be masked 


by storing a single byte in the interrupt-mask 
register 


contained 
by the PIC, whose four software-selectable 


priority 
algorithms 
are described 
in Table 5. The PIC 


generates 
a unique memory address for each interrupt 
level. These addresses 
are equally spaced at intervals 


of 4 or 8 bytes (software-selectable). 
The resulting 
32 


or 64-byte 
block 
may 
begin 
at 
any 
32 or 64-byte 


boundary 
in the 65,536-byte 
memory 
space. A single 


8080A jump 
instruction 
at each of these 
addresses 


then provides linkage to locate each interrupt 
service 


routine 
independently 
anywhere 
in memory. 


The 
two 
programmable 
timers 
may 
be used 
to 


generate 
real-time 
clocks by requesting 
periodic inter- 
rupts 
through 
the PIC, so that 
the CPU is free to 


handle 
numerous 
other 
system-timing 
and 
control 


functions. 
The outputs 
and gate/trigger 
inputs of the 


timer/counters 
can be routed via jumpers 
to the PIC, 
the 
I/O 
driver/terminators, 
or the 
programmable 


parallel 
I/O. 
Seven 
software-selectable 
timing/counting 
func- 
tions are available. 
Either 
timer may be set to act as 


a rate generator 
(divide-by-N 
counter), a square-wave 


4. By using the RMX·SO executive and the library of often- 
used subroutines, program development can be simplified 
since the subroutines are modular 
and can be linked 
together, then checked out in a system prototype. 
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Table 3. Non-Intel SBC-compatible boards 
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ADAC Corp" 118 Cummings Park. 
• 
451 
Woburn. MA 01801(617) 
935-6668 
Ampex, Memory Products Div,. 200 N_Nash St. 
• 
452 
EI Segundo, CA 90245,(213) 
640-0150 


Analog Devices. Route 1 Industrial 
Park. 
• 
453 
PO Box 280, Norwood, MA 02062,(617) 
329-4700 
Au~at Inc,. 33 Pera Ave,. P,O, Box 779, 
• 
454 
Att ebaro. MA 027 
3,(617) 222·2202 
BurrBrown. 
International 
Airgort In1EusYjai Park, 
• 
455 
PO Box 11400, Tucson, AZ 
5734,602 
294-1431 


Cybernetic Micro~stems. 
2460 Embarcadero Way. 
• 
• 
456 
Palo Alto. CA 943 
3,(415) 321·0410 


Data Translation Inc" 23 Strathmore Road. 
• 
457 
Natick. MA 01760,(617) 
655-5300 
Datacube Corp.. 25 Industrial Park. 
• 
458 
Chelmsford, MA 01824, (617) 256·2555 
Datel Systems Inc.. 1020 Turnpike St., Building S,. 
• 
459 
Canton. MA 02021(617) 
828·8000 
Digidata CO':!b8580 
Dorse~ Run Road, 
• 
460 
Jessup,MD 
0 94.(301) 4 8·0200 
EDAC Corp. 1417 San Antonio Ave.. 
• 
Alameda, CA 94501(415) 
521·6600 
461 
Electronic 
Engineering & Prod, Services, TE, #2, 
• 
462 
Louisville, TN 37777. (615) 984·9640 
Electronic Solutions. 7969 Engineer Rd. 
• • 
• 
San Diego. CA 92111(714) 
292·0242 
463 
Garry Mfg, Co" 1010 Jersey Ave" 
• 
464 
New BrunswiCk, NJ 08902,(201) 
545-2424 
Hal Communications 
Corp,. Box 365B. 807 E, Green St.. 
• 
Urbana. IL 61801 (217) 367· 7373 
465 


lasis, 815 W, Maude Ave., 
• 
Sunnyvale, CA 94086. 
(408) 732·5700 
, 
466 


ICOM, 6741 VaneIAve,. 
• 
Canoga Park, CA 91303, (213) 348-1391 
r 
467 
MegalO~ic Corp" 9650 National Road, 
• 
Brookvi Ie, OH 45309,(513) 
833·5222 
468 
Micro Memones Inc. 9438 Irond~le Ave, 
• 
Chatsworth, CA 91311(213) 
998-0700 
469 
Microtec 
P,O, Box 60337. 
• 
Sunnyvale. CA 94088,(408) 
733·2919 
470 
Monolithic Systems Inc. 
14 Inverness Drive. 
• • 
East. Englewood. CA 80110(303) 
7707400 
471 
~allonal Semiconductor, 
2900 Semiconductor 
Drive, 
• 
Santa Clara, CA 95051(408) 
737·5000 
472 
North Star Computers, Inc,. 2465 Fourth St.. 
• 
Berkeley. CA 94710,(415) 
549-0858 
473 
The Thomas Engineeri1: 
Co" 1201 Park Ave., 
• 
Emeryville, CA 94608,( 
15) 547·5860 
474 
Vector Electronic Products. 12460 Gladstone Ave, 
• 
Sylmar. CA 91342(213) 
365·9661 
475 
Zia Tech" 10762 La Roda Drive, 
• 
Cupertino, CA 95015,(408)996·7082 
I 
476 


generator, 
a programmable 
retriggerable 
one-shot, or 
software 
or hardware-triggered 
strobe. 
One of the 


timers 
can be jumper-selected 
as an event counter, 
and either can generate 
an interrupt 
after a specified 


interval 
or after 
a specified 
number 
of events. 


The programmability 
of each on-board timer allows 


timing 
intervals 
from approximately 
2 j.lS to over 60 


ms. But the two timers 
may be cascaded 
to provide 
intervals 
greater 
than 1.1 hour, in 1.86 j.lS increments. 
In the event 
counter 
mode, external 
event 
rates 
up 


to 1.1 MHz may be counted. 


Flexible I/O, a must for any system 


All SBC-80 microcomputers 
provide 
22 or 48 pro- 
grammable 
parallel 
I/O lines that, 
grouped 
as 8-bit 
ports, 
are fully programmable 
to allow enough flex- 
ibility 
to handle 
any changes 
in system 
interfacing. 


Programmability 
is permitted 
through data direction, 
control 
mode, 
interrupt 
handling, 
and 


buffer/termination. 
The I/O configuration 
for a spe- 


cific 
application 
is selected 
through 
software 
in- 


itialization 
of the parallel 
I/O control 
logic, jumper 
selection 
of control/interrupt 
line routing, 
and the 
particular 
buffer 
and termination 
devices chosen. 
Fig. 3 illustrates 
the basic modes of operation 
that 
may 
be selected 
by software 
to meet 
application 


requirements. 
Mode 0 is used for slow-to-medium- 
speed 
interfacing 
where 
immediate 
handshake 
re- 
sponse 
or interrupt 
generation 
is not needed. 
This 
mode is extremely 
useful for interfacing 
to inputs such 


as switches 
or outputs 
such 
as LED 
indicators 
or 


numeric 
displays. 


Mode 1 provides 
handshaking 
lines 
required 
for 


many 
medium 
to high-speed 
peripherals. 
A typical 
output function could be a line printer; 
an input device 
could be an encoded keyboard 
or paper tape reader. 
In addition, 
the 80!lOA and 80/20 have Mode 2, a 


bidirectional 
data/control 
structure. 
This 
interface 
may 
provide, 
for 
example, 
a communication 
link 
between 
parallel 
processors. 
The SBC·80 I/O 
structllre 
also permits 
multiple 
options 
for output 
buffering 
and input 
termination. 
TTL drivers 
with 
16 to 48 mA of drive can be used, 
and input 
lines may be terminated 
to minimize 
the 
impact of noise and cable disconnects. 
Any of the TTL 


drivers (four outputs) 
or input terminators 
(for inputs) 
listed in Table 6 may be inserted into sockets to provide 
proper 
buffering 
or termination. 
Like the design flexibility of the SBC-80 parallel I/O 
structure, 
the serial 
I/O structure 
allows 
interface 
characteristics 
to be revised rapidly through software, 
jumper, 
and buffer changes. Besides the SBC-80/10A, 
the 
80/20 
and 
80/20-4 
contain 
the 
USART 
serial 
channel. 
These boards provide RS-232 interfaces, 
but 
the SBC-80/lOA also has a teletypewriter 
current-loop 
interface. 
Synchronous/asynchronous 
mode, data for- 


mat, 
control-character 
format, 
and 
parity 
are 
all 


under program 
control. 
So is baud rate on the 80/20 
and 80/20-4. 
Baud rate 
is jumper-selectable 
on the 


AACK 
Advance-acknowledge 
signal, 
used 
in 


8080A-based 
systems. 
It is sent 
to the 


SBC-80 board by a memory 
bank in re- 


sponse to a m~mory-read command, allow- 
ing the memory to complete 
the access 


without requiring the CPU to wait. 


BCLK 
Bus clock, used to synchronize bus-control 
circuits on all master boards. Ithas a period 
of 101.725 ns (9.8304 MHz)and a 30to 70% 
duty 
cycle. The signal 
may be slowed, 


stopped or single-stepped. 


BPRN 
Bus-priority-input signal, used to indicate to 
the master 
that a higher-priority 
master 


board wants to use the system bus. When 
brought high, the signal suspends process- 
ing activity and places line drivers of the 
master 
in a standby mode. 


BUSY' 
Bus-busy signal, a bidirectional control line 
that allows control and monitoring of the 
Multibus in multi master 
SeUSYs. As an 


output from a bus master, 
indicates 


the bus is being used by the board. 
It 


prevents all other master boards from gain- 
ing 
control 
of 
the 
bus. 
Each 
master 


monitors SUS'i' as an input to determine 
current 
Multibus usage status. 


CCLK 
Constant clock, used to provide a 9.8304- 
MHzclock signal for 0~~17f1 
memory and 
I/O expansion boards. 
coincides with 


B'C[R and has a period of 101.725 ns and 
a 30 to 70% duty cycle. 


INIT 
Initialize signal, used to reset the entire 
system to a known internal state. 


INTR1 
Interrupt input, used to interrupt the proc- 
essor via an externally generated interrupt 
request. 


10RC 
I/O-read command, 
a signal generated 
by 


the master to indicate that the address of 
an 
input 
port 
has been 
placed 
on the 


system-address 
bus and that the data at 
that input port are to be read and placed 
on the system-data 
bus. 


10WC 
I/O-write command, 
a signal generated by 
the master to indicate that the address of 
an output 
port has been placed on the 


system-address 
bus and that the contents 


of the system-data bus are to be output to 
the add ressed port. 


MRDC Memory-read command, a signal generated 


by the master that indicates that the ad- 
dress of a memory location has been placed 
on the system-address 
bus. It specifies that 
the contents of the addressed location are 
to be read and placed on the system-data 
bus. 


MWTC Memory-write command, 
a signal gener- 
ated by the master 
to indicate that the 


address 
of a memory 
location has been 


placed on the system-address bus. Itcauses 
information on the data bus to be written 
into the addressed 
memory location. 


XACK 
Transfer-acknowledge 
signal, an input sig- 


nal to the master board from an external 
memory location or I/Oport to indicate that 
a specified read or write operation has been 
completed. 


80/lOA 
CPU board. 
The synchronous 
and asynchronous 
nature 
of the 


serial 
interface 
makes 
it compatible 
with 
virtually 
every 
standard 
serial 
data-transmission 
technique 


used 
today 
(including 
IBM's 
Bi-Sync). 
This 
allows 
multiple 
SBC-80 boards 
to be interconnected 
as a 
distributed-processing 
network. 
The resulting 
task 
segregation 
or 
redundancy 
(or 
both) 
significantly 
improves 
both system 
performance 
and reliability. 


Two jumper-selectable 
interrupt 
requests 
may be 
generated 
automatically 
by the serial 
interface. 
One 
occurs when a newly received 
character 
is ready 
to 


be loaded into the CPU (receive-channel 
buffer is full). 


The other 
occurs 
when 
new data 
are 
ready 
to be 
transmitted 
to the remote device (transmit-data 
buf- 


fer is empty). 
Both the SBC-80/04 
and 80/05 provide 
serial 
I/O 


capability 
through 
the serial 
input 
data 
(SID) and 
serial output 
data (SOD) functions 
of the 8085 CPU. 


These functions 
are controlled 
by software 
executing 
the 8085 read-interrupt 
mask (RIM) and set-interrupt 
mask 
(SIM) instructions. 


For systems 
requiring 
many 
serial 
channels, 
the 
SBC-534 communications-expansion 
board 
provides 
four USART 
channels 
with 
RS-232-C and optically 
isolated current-loop 
interfaces, 
programmable 
inter- 
rupt, 
timing, 
baud-rate 
control, 
and a Bell 801 Auto- 


Call unit 
interface. 


Expand the system via the Multibus 


The SBC-80 family is gaining not only in popularity 
but 
in support 
for its Multibus 
as more and more 
companies 
offer 
SBC-compatible 
boards. 
Intel 
now 
provides 
high-speed 
mathematics, 
RAM, 
EPROM, 
mass storage, 
digital 
I/O, combination 
memory 
and 


I/O, serial communications, 
and analog-I/O 
expansion 
boards. 
For 
applications 
requiring 
fast, 
high-precision 
number 
crunching, 
the SBC-3l0 math unit acts as an 


intelligent 
slave to perform 
floating-point 
and fixed- 
point 
mathematics. 
A processor 
uses 
the 
310 by 
passing 
parameters 
to it along with a command 
byte 


to select the desired operation 
from the SBC-310's 14 


instructions. 
The repertoire 
includes 
32-bit floating- 


point (single-precision) 
addition, 
subtraction, 
multi- 


plication, 
division, 
squaring, 
square 
root, 
com- 
parisons, 
and tests; 
16-bit fixed-point 
multiply, 
sub- 


tract, 
extended 
divide, 
and extended 
compare; 
and 


conversion 
from fixed to floating 
point or vice versa. 
A completed 
operation 
may be signaled 
either 
by 


the 
math 
unit 
via 
an 
interrupt 
or 
by 
the 
host 


processor's 
polling the "operation 
complete" flag in the 


unit's 
status 
register. 
The result 
may be retrieved 
at 
this point or left in the 310's accumulator 
for further 


use. 


In addition, the 310 provides control circuitry 
so that 


it may be treated 
as a "shared resource" among several 


CPU boards. 
Two diskette options are available for mass storage. 


Table 5. Programmable interrupt 
modes,SBC-80/20-4 


Mode 
Operation 


Fully 
nested 
Interrupt 
request 
line prior- 


ities fixed at 0 as highest, 
7 


as lowest. 


Autorotating 
Equal priority. 
Each level. af- 


ter 
receiving 
service. 
be- 


comes 
the 
lowest 
priority 


level until 
next interrupt 
oc- 


curs. 


Specific 
priority 
System software assigns low- 
est priority 
level. Priority 
of 


all other 
levels based in se- 


quence 
on this assignment. 


Polled 
System 
software 
examines 


priority-encoded 
system 
in- 


terrupt 
status 
via interrupt 


status 
register. 


Line drivers 


Driver 
Characteristic 
Sink current 
(mA) 


7438 
I.OC 
48 


7437 
I 
48 


7432 
NI 
16 


7426 
1.0C 
16 


7409 
NI,OC 
16 


7408 
NI 
16 


7403 
I,OC 
16 


7400 
I 
16 


Note: 
I = 
inverting; 
NI 
'" noninverting; 
OC 
!: open 
collector 


5V~ 
220 
INTEL sec 901 


':' 
330 
--- - - - - - - --- - ----- -------- 
- ----- 


5VO 
"..& 
OINTEL sec 902 


'k 


The SBC-201 diskette 
controller 
provides full control 
for one or two single-density 
diskette 
drives and acts 
as a programmable 
slave to masters 
on the Multibus. 


All diskette 
information 
is stored 
in the IBM soft- 
sectored 
format. 
For 
systems 
requiring 
greater 
storage capacity, the SBC-202 provides full control for 
up to four 
double-density 
diskette 
drives. 
Thus, 
2 


Mbytes of mass storage may be added to SBC-80-based 
systems 
for each SBC-202 plugged 
into the bus. 


Digital I/O may be expanded using any of three Intel 


boards. 
The SBC-519 provides 72 programmable 
par- 


allel I/O lines as well as interrupt 
handling and a real- 


time 
clock. 


The 519's clock can interrupt 
the appropriate 
CPU 


periodically 
so that the CPU can monitor 
system-I/O 


status. 
High-speed 
I/O 
events 
can gain 
the CPU's 


attention 
via interrupts. 
The SBC-517 combination 


I/O board and the SBC-104, 108 and 116 combination 
memory 
and I/O boards offer 48 programmable 
par- 


allel 
lines, 
a full 
RS-232 
USART 
serial 
channel, 


interrupt 
handling 
and a 16-ms real-time 
clock. The 


Table 7. RMX-80 routine library 


RMX/SO module 
Function 


Nucleus (executive) 
Provides 
basic 
capabilities 
(concurrence, 
priority, 
and 
synchroniza- 
tion/communication) 
found in all real-time systems, 


Terminal handler 
Provides real-time asynchronous I/O between an operator's terminal and tasks 
running under the RMX!SOexecutive, includes a line-edit feature similar to 
that of ISIS-II (supervisory system on the Intellec development system) and 
type-ahead facility, 


Diskette fiIe systems 
Diskette driver and file management capabilities, allows user to load tasks 
into 
the system and to create, access, and delete files 
in a real-time 


environment without disrupting normal processing, File formats compatible 
with ISIS-II for both single and double-density systems, 


Free space manager 
Maintains a pool of free RAM and allocates memory out of the pool upon 
request from a task; reclaims memory areas when no longer needed, 


Debugger 
Specifically 
designed for debugging software 
running 
under the RMX!SO 


executive; used by linking it to an application program or task, Thus, it can 
be run directly from the single-board computer's 
memory, 


Math handler 
Provides full control and communication 
for sse 310 math board for high- 


speed fixed and floating-point 
math functions, 


Analog interface handler 
Provides real-time control for sse 711, 724, and 732 analog I/O expansion 
boards, 


104, 108 and 116 also hold up to 8 kbytes of EPROM, 
along with 
4, 8 or 16 kbytes 
of RAM, respectively. 
For 
systems 
geared 
to especially 
noisy 
environ- 


ments, the SBC-556 provides 48 optically isolated I/O 
lines, which are configured 
as 24 input lines, 16 output 


lines, 
and 
eight 
programmable-I/O 
lines. The user 


fixes the optical-isolation 
characteristics 
according to 


his exact system requirements 
by installing 
the opto- 


isolators 
and current-limiting 
resistors 
of his choice 
into the board 
sockets, 
Input 
voltages 
up to 48 V, 
output 
lines up to 30 V and currents 
up to 60 mA may 
be interfaced, 
Of course, many more RAM, ROM, communications 


and interface 
options 
are available. 
But for systems 


to come together 
quickly during 
development, 
there 


must 
be some 
standardized 
operating 
software 
to 


provide 
some of the most fundamental 
system 
rou- 


tines. 


System software: the glue that binds 


Where the Multibus 
provides a standard 
hardware 
structure, 
RMX-80, a real-time 
multitasking 
executive 
supplies 
a 
modular 
software 
framework. 
With 


RMX-80, routines 
don't have to be developed for task 


synchronization, 
priority 
resolution 
and 
peripheral 


control (printers, 
terminals, 
diskettes, 
etc.). Versions 


are available 
for the SBC-80/20, 80/20-4 and 80/l0A 
CPU boards. 


Critical 
projects 
can be completed 
rapidly 
because 


RMX-80 provides 
major 
portions 
of the 
software 


requirements 
for many real-time 
systems. 
For exam- 


ple, the diskette file-extension 
software 
of the RMX-80 


program 
may 
be linked 
into the 
system 
software. 


Thus, 
users 
can 
immediately 
have 
a diskette 
file 
structure 
with facilities 
to open and close files, create 


and delete 
files, read or write 
files sequentially 
:.>r 


randomly 
(read 
function 
may 
be used 
for 
initial 


program 
load, 
if desired), 
or allocate 
file storage 


dynamically 
on single or double-density 
diskettes. 


The compactness 
of RMX-80-the 
entire 
executive 


resides in 2 kbytes of ROM-reduces 
memory require- 


ments and eliminates 
the need for bootstrap-program 


loading, All RMX-80 operations 
are based on individ- 
ual tasks. 
A task is a program 
with unique data and 
stack 
that 
operates 
asynchronously 
with other 
such 


programs 
in the system. 


Basically, 
the RMX-80 is a library 
of "standard" 


routines (Table 7), such as an analog-interface 
handler 
and 
a terminal 
handler. 
Fig. 4 illustrates 
how to 


develop 
software 
by selecting 
appropriate 
RMX-80 


modules, then locating and linking them with particu- 
lar 
software 
tasks 
on 
an 
Intellec 
microcomputer 


development 
system. 
In addition, 
a debugger 
module 
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5. 
This 
possible 
SBC·SO system 
configuration 
uses four 
5BC-80/05s 
to 
monitor 
and 
control 
pipeline 
parameters 


in the RMX-80 speeds real-time 
system development. 


The executive 
accesses system 
resources 
according 
to task priority, 
intertask 
communication, 
interrupt- 
driven 
control 
for standard 
devices, 
real-time 
clock 
control, 
interrupt 
handling, 
and other optional 
func- 
tions. In all, there are 255 separate 
task-priority 
levels, 
and since multiple 
tasks 
may share 
the same level, 
the actual number 
of tasks is limited only by memory 
size. 


Develop programs with the Intellec 


The Intellec 
and its ICE-80 and ICE-85 in-circuit 
emulators 
help minimize the time required 
to develop 
software 
and hardware. 
Standard 
Intellec stand-alone 
software 
includes 
resident 
macroassemblers 
for the 
8080A and 8085 CPUs, a text editor, 
and a system 
monitor/debugger. 
As 
a result, 
programs 
can 
be 
assembled, 
loaded, 
edited, 
executed, 
and debugged. 


ICE diagnostics 
can significantly 
reduce 
program 
development 
and debug time. 
Break 
points 
may be 
set on user-specified 
memory-read 
or write 
opera- 
tions, 
I/O read or write 
operations, 
or user-defined 
extension parameters. 
Programs 
can be single-stepped 
to check operating 
conditions 
and performance. 
PL/M-80 
is the high-level 
systems-programming 
language. 
The optional 
Intellec-resident 
PLiM 
com- 
piler provides 
the ability 
to program 
in this natural, 
algorithmic 
language, 
so there 
is no need to manage 
register 
usage or to allocate memory. PL/M programs 


and feed data back to a master 
controller, 
an 5BC-80/20-4. 


The master 
controller 
sends data 
back 
to a host 
system. 


6. 
Expanding 
the pipeline 
monitor/controller 
system 
is as 
simple 
as 
plugging 
more 
cards 
into 
the 
Multibus 
and 


altering 
the software. 
By adding 
another 
5BC-80/20 
to the 


master 
controller, 
some 
local 
processing 
can be done and 
a local 
CRT and 
high-speed 
printer 
can 
be added 
as well 
as RAM and 
diskette-memory 
space. 


may 
be linked 
to assembly-language 
programs 
to 


hasten 
product 
development 
further. 


A relocatable 
macroassembler 
residing 
on the In- 
tellec translates 
symbolic assembly 
language into 8080 


or 8085 machine 
code and 
permits 
the 
use of re- 
locatable 
and linkable 
object code. With full macro 


capability, 
similar 
sections of code needn't 
be written 
over and over. 


Intellec options include a diskette operating 
system, 


ISIS- II, with diskette controller, single or dual diskette 


Apply the SBe boards to real use 


To get an idea of the SBC 80 family's 
capabilities, 


examine 
the application 
shown in Fig. 5. In this case, 


a remote 
control/monitoring 
section 
of a pipeline 


supervisory 
control 
system 
grows 
with 
increasing 


requirements 
for 
additional 
local 
throughput 
and 


processing 
capability. 
Four 
SBC-80/05s 
act 
as 
remote 
pipeline 


monitors/controllers. 
Each unit monitors various con- 
tact closures 
(limit 
switches, 
relays, 
etc.) and a hex 


keypad, with a subset of its own I/O lines programmed 
as inputs. Contact debounce is performed 
in software. 


Other digital I/O lines on each SBC-80/05 act as output 
lines to drive a numeric 
display 
and various 
control 


relay 
coils. 


Analog-control 
lines are interfaced 
with an SBC-732 


combination 
analog-I/O 
board. 
Transducers 
indicat- 


ing temperature 
and pressure 
drive analog inputs, and 


analog outputs 
drive valves. Flow rate is determined 


in software 
by manipulating 
differential 
pressure 


data 
available 
from 
pressure 
transducers. 


The four 
80/05s 
are 
linked 
serially 
to a remote 


monitor/controllers. 
The 80/20-4 periodically 
queries 


each 
monitor 
to determine 
its current 
status. 
The 
concentrator 
also relays 
control 
commands 
from 
a 
host 
computer 
controlling 
the 
entire 
pipeline. 
The 


80/20-4's 
own RS-232-C serial 
channel 
provides 
the 
interface 
for this high-speed 
synchronous 
link to the 


host CPU. 


The 80/20-4 can contact the host CPU with the Bell 
801 automatic 
calling-unit 
interface 
on the SBC-534. 
The synchronization 
and control 
of communication 
between 
the four 80/05s and the host are handled 
by 


RMX-80 on the 80/20-4. 


The 80/20-4 system can be expanded to provide local 
processing 
capability, 
as shown in Fig. 6. Here, anoth- 
er 80/20 
is added 
as a second master 
on the Multi- 
bus to provide 
control 
for a local CRT and high- 


speed 
printer, 
and 
to 
provide 
local 
processing 
capabili ty. 


An additional 
32 kbytes 
of RAM are furnished 
by 


an SBC-032 RAM-expansion 
board. 
A third 
master, 


an SBC-202 dual-density 
diskette 
controller, 
can also 


be added 
to the 
Multibus, 
along 
with 
two double- 
density 
diskette 
drives. 
Communication 
between 
the 


two 80/20s 
is handled 
via user-written 
intermaster 
message 
tasks .•• 


DESIGN 
MOTIVATIONS 


FOR MULTIPLE 
PROCESSOR 


M'ICROCOMPUTER 
SYSTEMS 


Design decision factors involved in developing multiple processor 
microcomputer 
systems include means of minimizing 
contention for 
system bus utilization. 
System applications detail the appropriate 
hardware 
and software considerations 
as related to single-board 


computers in a multimaster 
bus structure 


Large-scale 
integrated 
circuit 
technology 
has reduced 
the cost of central 
processors 
to such a low level that 


the 
previously 
avoided 
concept 
of 
applying 
multiple 
processors to meet system performance 
requirements 
has 
now become an attractive 
and viable alternative. 
Several 


key benefits accrue from such an approach. 
In addition 


to enhanced system performance 
(throughput), 
improved 


system 
reliability, 
and 
improved 
system 
realtime 
re- 


sponse, 
modular 
system expansion 
capabilities 
may be 
realized. 
Although 
designing 
such 
systems 
"from 


scratch" 
with 
microprocessor 
component 
families 
can 


be a complex system design task with many subtle pit- 
falls 
which 
can 
inhibit 
efficient system 
operation, 
the 
advent 
of 
second 
generation 
single-board 
computers, 
such as the Intel® SBe 
80/05 
and 80/20, 
has allowed 


multiple 
processor 
microcomputer 
systems 
to 
become 
off·the·shelf products. 


Discussion of the benefits of multiple processor structures 
in system applications 
will provide 
an understanding 
of 


the motivation 
for this implementation 
approach 
in sys- 


tem 
design. 
A 
primary 
objective 
addressed 
through 
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multiple 
processor 
approaches 
is enhanced 
system per- 
formance 
and 
throughput. 
Enhanced 
performance 
is 
achieved through partitioning 
of overall system functions 


into tasks 
that 
each 
of several 
processors 
can 
handle 


individually. 


In 
general, 
as the 
number 
of individual 
tasks 
any 


given processor must handle is reduced, that processor's 
response time to new requests for service will be reduced. 
A well planned 
multiple 
processor 
bus 
structure 
will 
allow 
new 
processors 
to be 
added 
to 
the 
system 
in 


modular 
fashion. 
When new system functions 
(ie, more 
peripherals) 
are added, 
more processing 
power can be 
applied to handle them without 
impacting 
existing 
pro- 
cessor (master) 
task partitioning. 


As used here, a "master" 
is any element existing on the 
system bus that may take control 
of the bus 
(ie, assert 


address 
and 
control 
lines). 
Typical 
examples 
include 


processors 
and direct memory 
access (DMA) controllers 


that address 
memory 
and input/output 
(I/O) 
locations 
resident 
on the bus. 
"Slave" 
elements 
include 
passive 


functions 
on the bus, such as memory 
or non·DMA I/O 
interfaces. Note that although 
slaves may possess intelli· 


Fig 1 
Multiple 
processor 
bus structure. 
Dual onboard/offboard 
structure 
of MULTIBUS allows each master to use its 
own memory and 1/0 
without 
utilizing 
common system bus (a). Only when a master requires access to common mem- 
ory or 1/0 does it use the bus (b). Note that other masters 
may continue 
onboard 
operations 
simultaneously 


EXTERNAL 
INTERRUPT 
REQUEST 
LINE 


9 INTERRUPT 


"'T"" 


Fig 2 
SBC 80105 
block diagram. 


SBC 
80105 
is 
a full 
microcom- 


puter 
on 
a single 
PC board. 
It 


provides 
8085 CPU plus RAM for 


program or data storage, EPROMI 
ROM for 
program 
storage, 
inter- 


val timer, 
programmable 
parallel 


1/0 
(22 
lines), 
serial 
1/0, 
and 


full 
MULTIBUS 
multi master 
con- 


trol 
logic 
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Hardware 
considerations 
must be thoroughly 
evaluated 
in any multiple 
processor 
bus structure. 
These 
factors 


are described 
in detail around 
a specific implementation 


of such a structure, 
the Intel" 
MULTIBUS™, 
which sup- 


ports 
multiple 
processor 
systems 
with 
its multi-master 


bus structure. 


One architectural 
option open to the system designer 
is 


that 
of a multiple 
master/single 
bus 
structure. 
Under 


this partitioning, 
every master 
utilizes the common 
bus 


data 
path 
to fetch instructions 
or data 
from 
memory, 


read 
data 
from 
input 
devices, or write 
data 
to output 


devices or memory. 
Therefore, 
the common 
system bus 


rapidly 
becomes 
the 
bottleneck 
for 
overall 
system 


throughput, 
and fast 
DMA 
transfers 
can easily approach 


the full bandwidth 
of the bus during 
block transfers 
so 
that 
all other 
masters 
must 
idle for 
extended 
periods. 


system 
retains 
its ow~ local 
memory 
and 
I/O that 
it 


utilizes for most operations. 
Such local operations 
occur 


totally 
on the individual 
board 
and do not require 
the 


system 
bus. 
This 
greatly 
reduces 
the 
service 
request 


frequency by each master requiring 
use of the system bus. 


Such a dual·bus 
structure 
is implemented 
on the SBC 


80/05 
and 80/20 
single·board 
computers, 
as shown 
in 


Figs 2 and 3, respectively, 
with the multi·master 
system 
bus 
(MULTIBUS) 
.'.2 
Access to the system 
bus is requested 
only 
when 
a 


global 
(resident 
on the bus and accessible 
by multiple 


masters) 
memory 
location 
or 
I/O 
device 
is referenced 


during 
an instruction 
execution 
cycle. Local/global 
(on. 


board/offboard) 
distinction 
is defined through 
the value 


of the physical 
address 
referenced. 
If it lies within 
the 


address range of onboard 
memory or I/O, no bus request 


is made. 
Only 
when 
the 
address 
references 
a 
global 


USER DESIGNATED 


PERIPHERALS 


48 PROGRAMMABLE 
PARAllEL 
I/O LINES 


Fig 3 
SBC 80/20·4 block diagram. SBC 80/20-4, also a full microcomputer on a single PC board, provides 8080A-2CPU, 
4k bytes of RAM, up to 8k bytes of EPROM/ROM,48 programmable I/O lines, three interval timers, full RS-232-C serial 
port, 8-level priority interrupt logic, and MULT1BUSmultimaster control logic 


memory or 1/0 location, is a system bus request initiated. 
If no other 
master 
is currently 
utilizing 
the bus, 
this 


"new" 
master 
will be granted 
access immediately. 
How. 


ever, this 
new master 
must 
wait 
if another 
master 
is 


currently 
utilizing the system bus. It continues to monitor 


the status of the system bus to determine 
when its cur· 
rent cycle may be completed. 
Thus, the 
MULTIBUS 
must 


provide 
a method 
for masters 
to determine 
whether 
or 
not another 
master is currently 
utilizing 
it. 


Other 
masters 
may 
also 
simultaneously 
request 
the 


system bus. Arbitration 
must then be performed 
to reo 


solve this multiple 
contention 
for the system bus. The 


MULTIBUS 
structure 
provides 
this 
arbitration 
in one of 


two 
lechniques: 
serial 
(daisy 
chain) 
or 
parallel 
(en. 


coded). 
The structure 
consists of four control lines that 


are synchronized 
by the common bus clock. These four 


control 
lines and the bus clock are active low. This is 


represented 
by the slash (/) 
character 
after each signal 


mnemonic. 
Control lines are as follows: 


Bus Clock 
(BCLK/) 
-The 
negative 
edge of BCLKI 
is 


used to synchronize 
bus arbitration. 
BCLKI 
may be asyn- 


chronous 
to all CPU clocks, and it has a 100-ns minimum 


period. 
BCLKI 
may 
be 
slowed, 
stopped, 
or 
single. 


stepped for debugging. 


Bus 
Priority 
In 
Signal 
(BPRN/)-Indicates 
to a par- 


ticular 
master that no higher 
priority 
master 
is request- 
ing use of the system bus. 


Bus Priority 
Out Signal 
(BPRO/)-Used 
with serial bus 


priority 
resolution 
scheme. BPROI 
is passed to BPRNI 
input of master with next lower bus priority. 


Bus Busy 
Signal 
(BUSY/)-Driven 
by bus master 
cur- 
rently 
in control 
of 
MULTIBUS 
to indicate 
that 
bus 
is 


currently 
in use. BUSYIprevents 
all other masters 
from 


gaining 
control 
of bus. 


Bus 
Request 
Signal 
(BREQ/)-Used 
with parallel 
bus 
priority 
network 
to indicate 
that a particular 
master 
reo 


quires 
use of the bus for one or more data transfers. 


Serial (Daisy-Chain) 
Bus Arbitration 


In a serially 
arbitrated 
MULTIBUS 
system 
(Fig 
4) 
re- 


quests for system bus utilization 
are ordered 
by priority 


on the basis 
of bus location. 
Each master 
on the bus 


notifies the next lower priority 
master 
when it needs to 


use the bus for a data transfer, 
and it monitors 
the bus 


request 
status 
of the next higher 
priority 
master. 
Thus 


the masters pass bus requests along from one to the next 
in a daisy-chain 
fashion. 


The highest priority 
master 
(Master 
1) in the system 


will always 
receive 
access 
to 
the system 
bus 
when 
it 


requires 
it. There is no higher priority 
master to inhibit 


its bus requests, and its bus priority 
input line (BPRN/) 


is thus permanently 
enabled. 


Masters 
operate 
asynchronously 
on the 
MULTIBUS. 
A 


master 
may thus 
be in the middle 
of a bus operation 


when 
a higher 
priority 
master 
requests 
the 
bus. 
Ob- 


viously, 
interruption 
of such 
an 
in· process 
cycle must 


not 
be 
allowed. 
The 
mechanism 
for 
avoiding 
such 


erroneous 
operation 
is the 
BUSYI 
line. 
Upon 
being 


notified 
that 
access to the bus 
is possible, 
the master 


examines 
BUSYI. If this 
control 
line 
is inactive, 
the 


master 
will assert 
it, and 
complete 
its 
bus 
operation. 


If BUSYI is already 
active, another 
master 
is currently 


using 
the 
bus. 
In 
this 
case, 
the 
master 
will examine 


BUSYI 
upon 
every 
falling 
edge 
of BCLK/, 
typically 


once 
every 
100 
ns, 
until 
it 
becomes 
inactive. 
When 


BUSYIretums 
to its inactive state, the master will assert 


it, then complete 
its operation. 
The BUSYIline 
then in· 


hibits 
higher 
priority 
masters 
from 
destroying 
a bus 


transfer 
cycle that may be already 
in progress. 


The 
BUSYI line 
is also 
controlled 
by 
a bus 
lock 


function 
on the SBC 8010S 
and 
80/20. 
This 
function 


allows a master, which currently 
has control 
of the bus, 


to retain 
control 
by independently 
asserting 
the BUSY1 


line 
until 
it 
issues 
an 
unlock 
command 
that 
releases 


BUSYI. This permits 
a bus master 
to obtain 
exclusive 


control 
of the system bus for critical 
system functions, 


Fig 4 
Serial bus arbitration. When any master 


requires use of MULTIBUS in serial (daisy-chain) 
priority mode. its BPROI line inhibits lower prior- 
ity masters 
from system bus utilization. BUSYI 


line is used to ensure that in-process operations 
of lower priority masters 
are 
not destroyed 
by 


asynchronous 
bus 
requests 
of 
higher 
priority 


masters 


such as high 
speed memory 
or 
I/O data 
transfers 
and 


critical 
read·modify·write 
operations. 
With 
BUSY/ 
asserted 
in this way, all other masters 
will find the bus 


"in use" when they attempt to access it. Whereas system 
bus transfers 
uormally take place on an Interleaved basis 


(bus 
arbitration 
performed 
for 
each 
cycle), 
this 
bus 
lock function 
permits 
fast multiple.word 
transfers, 
when 


needed. 


Two basic parameters 
determine the number of masters 
that can coexist on the system bus in serial bus arbitra· 
tion 
mode. 
These 
are 
the BCLK/ 
cycle time 
and 
the 
BPRN/ 
to BPRO/ 
propagation 
delay 
of bus masters. 
Masters may be added to a system as long as the cumula- 
tive BPRN/ 
to BPRO/ 
propagation 
delay is such that the 
lowest priority 
master 
will always have its BPRN/ 
line 


driven inactive before the next BCLK/ 
falling edge after 
the highest priority 
master requests the bus. This worst. 


case timing 
condition 
is met as long as the following 
relationship 
is satisfied. 


N-l 


~ 
(tllr'ltX_IlI'RO) 
I < Illn.K 
- 
Lh 
i=l 


where 


(tRI'It'i_RrRO) 
l = Propagation 
delay 
for 
master 
i 


tllCLK 
= Bus 
clock 
(nCLK) 
cycle 
time 
(period) 


t5h = Allowance 
for bus 
setup 
and 
hold 
times 


N = Number 
of bus 
masters 


Using 
serial 
bus 
arbitration 
and 
SBC 80 
onboard 


clocks, up to three 
masters 
may coexist 
on the system 


bus. This number 
can easily be extended, 
if desired, 
by 


generating 
a BCLK with a longer cycle. The SBC 80/05 


and 80/20 
provide 
a jumper 
option 
which 
allows 
the 


onboard 
BCLK/ 
to be disabled. 
This allows the system 
designer 
to generate 
BCLK/ 
externally. 


Parallel (Hardware-Encoded) 
Bus Arbitration 


The 
parallel 
bus 
arbitration 
technique 
resolves 
system 


bus 
master 
priorities 
using 
external 
hardware. 
The 


parallel 
multimaster 
control 
line 
(BREQ/) 
comes 
into 


force in this case. Each master 
asserts 
BREQ/ 
when it 


requires 
access to the system bus. These lines are 
fed 


to 
a 2·chip 
parallel 
priority 
network. 
As 
with 
serial 
priority 
resoluti'on, BPRN/ 
acts as the bus access enable 


input to each master. 
As Fig 5 illustrates, 
up to eight 
master 
priority 
levels are encoded 
by a 74148 priority 
encoder to a 3·bit code representing 
the highest 
priority 
master 
currently 
requesting 
the system 
bus. This 
code 


drives the 8205 3·to-8 decoder 
which asserts the proper 
BPRN/ 
line 
low 
to 
grant 
bus 
access 
to 
the 
highest 
priority 
master. 
The 
74148/8205 
propagation 
delay 
is 


less than 40 ns, easily fast enough to allow eight masters 
to coexist in this configuration 
utilizing 
a BCLK/ 
with 
a 100-ns period. 
Systems requiring 
up to 16 masters may implement bus 
arbitration 
by utilizing two 74148 priority 
encoders 
and 


two 8205 decoders 
to provide 
a 16-level hardware 
pri- 


ority network. The actual number of bus masters feasible 
on the system bus will also depend on bus drive/loading 
considerations. 
Even 
under 
this 
consideration, 
systems 


containing 
up to 16 masters are feasible. 


Thus, 
single-board 
computer 
masters, 
in conj unction 
with the MULTlBUScontrol structure, 
provide off-the·shelf 
hardware 
solutions for the development of efficient multi- 
ple processor microcomputer 
systems. In addition 
to this 


hardware 
capability, 
the system designer 
needs to con- 
sider several software 
design issues. 


Several 
software 
operations, 
such as mutual 
exclusion, 
communication, 
and 
synchronization, 
are 
essential 
to 


proper 
multiple 
processor 
system 
operation. 
The 
MULTlBUS/SBC 80 functions 
that 
enable 
these 
software 
operations 
are examined. 


Mutual Exclusion 


In a multiple processor 
microcomputer 
system, there are 


Fig 
5 
Parallel 
bus 
arbitration. 
Under parallel 
bus 


arbitration structure, 
multiple requests 
for access 
to 


the MULTIBUS are 
determined 
by 2-chip hardware 


priority network. When simultaneous multiple bus re- 
quests occur, only highest priority master has its bus 
grant (BPRN/) line asserted. BUSY/line inhibits other 
masters 
from interfering with system 
bus cycles 
in 


progress 


usually 
many resources 
that are shared 
by the processors. 


Such 
shared 
resources 
include 
common 
memory 
and 


peripherals. 
A properly 
functioning 
system must provide 


a mechanism 
to guarantee 
that 
asynchronous 
access 
to 
those 
resources 
is controlled 
in 
order 
to 
protect 
data 
from 
simultaneous 
change 
by 
two or more 
processors. 


Thus, 
some form 
of mutual 
exclusion 
must 
be provided 


to enable 
one processor 
to lock out 
access 
of a shared 


resource 
by 
other 
processors 
when 
it 
is 
in 
a critical 


section. 
A critical 
section 
is a code 
segment 
that 
once 
begun 
must 
complete 
execution 
before 
it, 
or 
another 


critical 
section 
that 
accesses 
the 
same 
shared 
resource, 


can be executed. 
A Boolean 
variable 
can 
be used 
to indicate 
whether 


a processor 
is currently 
in a particular 
critical 
section 


(true) 
or not 
(false). 
Testing 
and 
setting 
this 
variable 


also 
presents 
a critical 
section. 
This 
function 
must 
be 
performed 
as a single 
indivisible 
operation; 
if it is not, 
two 
or 
more 
processors 
may 
"test the 
variable 
simul- 


taneously 
and 
then 
each 
set it, allowing 
them 
to enter 


the critical 
section 
at the same time. 
Such 
simultaneous 


entry 
would 
destroy 
the 
integrity 
of data 
and 
control 


parameters 
in global 
memory 
or cause erroneous 
double 
initialization 
of a global peripheral 
controller. 
Mutual 
exclusion 
can 
be implemented 
as a software 
function 
alone, 
as described 
by Dijkstra\ 
for n proces- 


sors 
operating 
in parallel. 
The 
SBC 80/05 
and 
80/20 
bus 
lock 
function 
mentioned 
earlier 
provides 
a means 
for using 
program 
control 
to simplify 
mutual 
exclusion. 


While the system 
bus is locked, 
the master 
can perform 


the 
indivisible 
test 
and 
set 
operation 
on 
the 
Boolean 


variable 
used to control 
access to a critical 
section 
with- 


out intervention 
from 
other 
masters. 


Communication 
is 
an 
essential 
function 
that 
allows 
a 


program 
executing 
on one processor 
to send 
or receive 


data 
from 
a program 
executing 
on 
another 
processor. 


Typically, 
two 
processors 
communicate 
through 
buffer 


storage 
in 
common 
memory. 
One 
program, 
called 
a 


producer, 
adds 
data 
to buffer 
storage; 
another, 
called 
a 


consumer, 
removes 
information 
from buffer 
storage. 


In 
a 
typical 
application, 
one 
master 
may 
produce 


buffers 
of data 
that 
are 
to be consumed 
by a program 


executing 
on 
another 
master 
that 
services 
an 
output 


device. 
Communication 
through 
buffer 
storage 
requires 


the 
operations 
of 
adding 
to 
and 
taking 
from 
buffers. 


These 
operations 
constitute 
critical 
sections 
that 
can be 


controlled 
by 
providing 
mutual 
exclusion 
around 
the 


buffer 
manipulation 
operations. 


Synchronization 


At times 
there 
is a need for one master 
to send 
a syn- 


chronization 
signal to another. 
In a sense, synchronization 


is a special 
case 
of 
communication 
during 
which 
no 


data 
is transferred. 
Rather, 
the act of signaling 
is used 


to 
"wake 
up" 
a program 
executing 
on 
another 
master. 


A program 
may "sleep," 
by waiting 
for a synchronizing 


signal, 
until 
it receives 
a wake-up 
signal 
that 
enables 


it to continue 
execution. 
Manipulation 
of synchronization 


signals 
requires 
mutual 
exclusion. 


Fig 
6 
Multiple 
processor 


communication 
application. 


Multiple 
processors 
may 
be 


utilized to increase throughput 
in 
system 
requiring 
several 


high 
speed 
serial 
channels. 


sse 
80/05 single-board 
com- 


puter 
controls 
four RS-232-e 


or 20-mA serial 
channels 
in- 


terfaced 
to 
system 
through 


sse 
534 communication 
ex- 


pansion 
board. Second 
single 


board 
computer 
(SSe 
80/20) 


retrieves 
data 
records 
con- 


structed 
by sse 
80/05 
and 


performs further processing 


System Initialization 


In a microcomputer 
system that has multiple processors 
sharing 
a common 
system bus, 
a system 
initialization 
mechanism must be designed to set up the variables that 
control 
access to the shared 
resources. 
All single-board 
computers 
on 
the 
MULTIBUS 
begin 
execution 
simulta. 
neously following a system reset. The bus lock function 
of the computers 
can be used by one specifically desig. 
nated master 
to lock the bus immediately 
upon system 
reset and to perform 
system initialization 
for common 
resources 
before 
any 
other 
master 
attempts 
to 
access 
them. Since a locked bus has no effect on a single· board 
computer 
that is executing 
out of its local memory and 
using its local I/O, normal initialization 
by each processor 
can proceed while the shared resource initialization 
takes 
place. 


Multiprocessor 
Applications 


Two applications 
that 
are well suited 
to multiple 
pro- 
cessor 
microcomputer 
systems 
are examined. 
The 
first 
provides 
increased 
throughput, 
and 
the 
second 
allows 
shared 
resources. 


Increased Throughput 


Consider a system that is controlling multiple high speed 


serial communication 
channels in addition 
to other data 
processing 
activities. 
In this 
case, 
multiple 
processors 
may be utilized 
to increase 
system throughput. 
Such a 
system 
with 
four 
full-duplex 
serial 
channels 
operating 
at 4800 baud 
could 
produce 
interrupts 
every 
250 
JAS. 
Interrupts 
at that 
frequency 
in a single master 
system 
would leave little time 
for 
other 
processing 
activities. 


In a multiple processor 
approach, 
one processor 
can be 
used to handle 
the interrupts 
from the serial 
channels, 
accumulate 
data 
into 
records, 
and 
then 
provide 
those 
records 
to another 
processor 
by placing 
them in com· 
mon 
memory. 
The 
second 
processor 
is not 
burdened 
with 
the 
overhead 
of handling 
each 
character 
on 
an 
interrupt-driven 
basis, 
instead 
it is sent entire 
records 
of data available for further 
processing. 
As shown in Fig 6, this application 
can be handled 
on the 
MULTIBUS 
with 
four 
boards. 
The 
SBC 80/05 
single. board 
computer 
is used to service the communi. 
cation board and prepare 
the data records. A 4·channel 
serial communication 
board 
(SBC 534) 
is used to pro· 


vide the hardware 
interface 
for four serial communica. 
tion channels. The SBC 80/20 
single.board 
computer 
is 
used to process data records prepared by the SBC 80/05. 
Common 
memory 
is provided 
by 
the 
SBC 016 
16k 
random-access 
memory 
(RAM). 
Application 
of multiple 
processors 
to this 
problem 
requires 
communication 
through 
buffer 
storage. 
Two 
primitive 
operations, 
introduced 
by 
Dijkstra" 
can 
be 
used to simplify the communication 
and synchronization 
between the masters. These primitives, 
designated 
P and 
V, 
operate 
on 
non-negative 
integer 
variables 
called 


Fig 7 
Multiple processor 
shared-resou rce 
a ppIica- 
tion. 
MULTIBUS multiple 
processor 
structure 
allows 
two 
independent 
single- 
board computers to share 
common system resource, 
such as an SBe 310 high 
speed math board, to per- 
form floating point opera-· 
tions 


semaphores. 
The 
V 
procedure 
increments 
the 
sema- 


phore 
(5) 
in a single indivisible 
operation. 
To make 


certain 
that 
fetch, increment, 
and store 
are not 
inter- 


rupted 
by another 
processor, 
the bus is locked during 


the operation. 


Procedures 
for P and V primitive 
operations 
can be 


implemented in PL/M6 as follows: 


v, 
PROCEDURE 
(SIAORJ 
; 
DECLARE 
S BASED 
SIADR 
BYTE; 
OUTPUT(BUSJLOCK) 
= LOCK: 
S = S+I: 
OUTPUT<BUSSLOCK) 
= UNLOCK: 
END v: 


"Lork 
MIII.TIDUS 
'/ 


"In('r~ml:nt 
Kmaphore" 


" 
Unll)("k 
MULTIBU5" 


The P procedure loops in a busy wait until 5 is greater 
than 
zero, at which time it decrements 
5. The act of 


fetching, testing, decrementing, 
and storing 5 is also an 
indivisible 
operation. 
Note that if several masters 
with 


different 
speeds are in a busy wait on the same sema- 


phore, the solution presented 
may not be "fair" 
to the 
lower speed processor; 
that is, the lower speed processor 


would test the semaphore 
less frequently, 
resulting 
in 


an unfair 
advantage 
for higher 
speed processors. 
Implementation 
of a procedure 
for the P primitive 
is 


shown in the following 
PL/M code. 


P, 


PROCEDURE(SSADR) 
; 
DECI.ARE 
S BASED SSADR 
BYTE: 
DO FOREVER, 
IF S > 0 THEN 
DO: 
OUTPUT<BUSSLOCK) 
= LOCK: 


IF S > 0 THEN 


-DO: 
S = 5-1; 
OUTPUT(BUSSLOCK) 
= UNLOCK; 


RETURN: 
END: 
OlJTPUT<BUSSLOCK) 
= UNLOCK: 


END; 
END: 


END P: 


" 
De('rem~nt lil:maphare 
'/ 
/' 
UnJo('k 
MtJLTlBUS 
" 


" 
E.it from P procedure " 


It is important 
to observe in the program 
listing that 5 


is tested prior 
to issuing 
a bus lock. This 
initial 
test 
avoids continuous 
locking and unlocking 
of the system 
bus while looping 
in a busy wait. The second test is 


required because another processor could also have found 
5 greater than zero and tried to enter the critical section 
at the same time. 


With the P and V operations, semaphores can be used 


as resource counters in the buffer manipulation 
required 


'for communication 
between the 5BC 80/05 
and 80/20. 
For example, a consumer 
program 
can use the P oper- 


ation to decrement the number of full buffers and a V 
operation 
to increment 
the number 
of empty 
buffers. 
In a similar 
fashion, 
a producer 
program 
can use the 
P operation 
to decrement 
the number 
of empty buffers 


and 
a V operation 
to increment 
the 
number 
of full 


buffers. In addition 
to full and empty buffer counters, 
it is necessary to maintain 
linked lists pointing to actual 


full and 
empty 
buffers. 
A semaphore 
can be used to 


provide 
mutual 
exclusion 
around 
the manipulation 
of 


the 
linked 
lists. 
In 
the 
example 
that 
follows, 
three 


variables 
(FULL, 
EMPTY, and SEMA) are used to imple- 
ment these functions. The two PL/M programs 
illustrate 


consumer 
and 
producer 
code 
segments, 
respectively. 


Note that the consumer 
performs 
initialization 
because 


it accesses the semaphores prior to the producer. 


CONSUMER, 
DECLARE 
EMPTY 
BYTE 
EXTERNAL: 


FUI.L 
BYTE 
EXTERNAL: 
SEMA 
BYTE 
EXTERNAL: 
OUTPUTCBUSSLOCKI 
= LOCK: 


EMPTY = NUMBSBUFFERS: 
FULL = 0; 
SEMA = I: 
OUTPUT(BUSSLOCK) 
= UNLOCK: 


DO FOREVER: 
CALL P(FULLl: 
CALL P(SEMA): 


"Number 
of empty 
buften" 


" 
Number of full huften 
'/ 
" 
Binary 
semaphore 
" 


" 
Lock 
MULTIIUS 
'/ 
" 
Initialize 
semaphores 
'/ 


" 
Decrement 
full 
buffer 
'/ 


" 
aemaphore" 


" 
Decrement 
mutual 
uclu.ion 
" 


" 
semaphore" 


ITake 
data 
from 
buffer 
and 


place 
it in local 
memory. 
move buffer from full 10 
empty 
linked 
list) 


" 
Increment 
mUlual 
exclusion" 


" 
5I'maphore" 


" 
Increment 
empty 
buffer 
" 


,. 
semaphore·' 


END; 
END CONSlJ'oIER; 


PRODUCER, 


DECLARE 
(EMPTY. 
FULL, 
SEMA) 
BYTE 
EXTERNAL; 


DO FOREVER; 


,. 
Decrement 
empty 
buffer 
semaphore 
., 
,. 
Decrement 
mutual 
exclusion 
., 
,. 
semaphore·' 


(Place 
data 
in a buffer, 
move 
buffer 
from 
empty 
to full 
linked 
list) 


,. 
Increment 
mutual 
exclusion·' 


,. 
semaphore·' 


,. 
Increment 
full 
buffer 
semaphore 
., 


END: 
END PRODUCER: 
Shared Resources 


Another 
typical 
application 
for 
a 
multiple 
processor 


microcomputer 
system would be to allow sharing 
of a 


resource by two processors. 
For example, consider 
two 


independent 
processors that have a need for high speed 


mathematical 
functions. Although it inay not be possible 


to justify 
a high speed math module for each system, 


such a module might be justified if it were to be shared 
by both processors. A multiple processor microcomputer 
system could provide the capability 
to allow both pro- 


cessors to share the math module and not interfere with 
their otherwise unrelated functions. 


This 
application 
(illustrated 
in 
Fig 
7) 
could 
be 


handled with four boards. The 5BC 80/05 
single.board 


computer 
is used to perform 
various 
data 
processing 


functions requiring 
high speed floating-point arithmetic. 


The 5BC 80/20 single-board computer controls a process 
where high 
speed numeric 
computations 
are 
required. 


High 
speed 
floating-point 
mathematics 
functions 
for 


both single. board 
computers 
are performed 
by an 5BC 


310 high speed math unit. 5BC 116 combination 
memory 


and 
I/O board 
provides 
16k !lAM, 8k electrically 
pro· 


grammable 
read-only 
memory 
(EPROM) , 
48 
parallel 


I/O lines, and an R5-232·C serial port. 


The problem 
to be solved in this 
application 
is to 
ensure that only one processor 
has access to the shared 
math 
module 
resource 
at 
one time. 
Thus, 
mutual 
ex- 
clusion 
must 
be provided 
to control 
the access to the 
resource. 
The 
following 
PL/M 
function 
returns 
TRUE 


if access to a critical 
section, 
used to 
implement 
the 
mutual exclusion, has been granted. 


ENTERtcRITICALfSECTlON, 


PROCEDURE 
IFLAGfADRl 
BYTE; 


DECLARE FLAG BASED FLAGlADR 
BYTE; 


DECLARE ACCESS BYTE; 


IF FLAG = BUSY THEN 
RETURN FALSE; 
ACCESS = FALSE; 
OUTPUTlBUSlLOCKl 
= LOCK; 
IF FLAG = NOT BUSY THEN 
DO; 


FLAG = BUSY; 
ACCESS = TRUE; 


END; 
OUTPUTIBUSlLOCKI 
= UNLOCK; 


RETURN ACCESS; 
,- 
Unlock 
MULTIIUS-' 
,- 
Return 
either 
TRUIE or • J 


,- 
FALSE 
acceu 
-, 


This 
PL/M 
function 
first 
tests 
the 
flag for 
the 
busy 
condition 
before 
issuing 
a busy lock. As in the P pro- 
cedure 
described 
earli~r, 
this 
initial 
test 
avoids 
con- 
tinuous locking and unlocking 
of the 
MULTIBUS 
while a 
busy wait 
is being 
executed. 
The 
following 
procedure 
performs 
a busy 
wait 
operation 
on the 
flag used 
to 
control access to a critical 
section. 


BusnWAIL 


PROCEDURE 
IFLAGlADRl; 
DO WHILE NOT ENTERlCRITICAUSECTION 
(FLAGlADRl; 
END; 
END BUSnWAIT; 


Typical code segments illustrating 
the use of these pro· 


cedures 
follow. 


DECLARE 
MATH'DO,FLAG 
BOOLEAN 
EXTERNAL 
i 
,- 
Flag must be -, 
,- 
initialized-' 


/- 
We could 
also 
telt 
and then 
do tome 
olher 
-, 
Ie 
processinc 
if the math 
module 
is busy 
-, 


IF ENTERfCRITICAUSECTlON 
(.MATHlBDlFLAG 
l 


THEN DO; 


MATHSOOSFLAC 
= NOT BUSY; 
,- 
Set flail nol buS)'-' 


END; 


ELSE DO; 


The 
motivations 
for 
implementing 
multiple 
processor 
microcomputer 
systems 
include 
enhanced 
performance 


and 
throughput. 
When 
the 
appropriate 
hardware/soft- 


ware 
design 
considerations 
are 
made, 
modularity 
is 


easily 
achieved. 
Hardware 
solutions 
to many 
problems 


are 
provided 
by means 
of a 
MULTIBUS 
structure 
and 
SBe 80 single-board 
computers 
that 
have multimaster 


capability. 
Through 
control 
of 
MULTIBUS 
functions, 
the 


software 
designer 
can perform 
multiple 
processor 
com- 


munication, 
synchronization, 
and mutual exclusion. 


Even with these significant 
steps toward 
the simplifi- 


cation of multiple processor 
microcomputer 
systems, the 


design 
of such 
systems 
remains 
a complex 
software/ 


hardware 
design 
task. 
The 
future 
trend 
of 
multiple 


processor microcomputer 
systems will be to simplify the 


software 
tasks 
of 
implementing 
communications, 
syn- 


chronization, 
and 
mutual 
exclusion. 
These 
functions 


could 
be performed 
in varying 
degrees 
by 
additional 


hardware 
bus functions. 
Potential rewards for a multiple processor architecture 


include enhanced 
system throughput, 
improved 
real-time 


response, modular 
system expansion, 
and improved 
sys- 


tem 
reliability. 
These 
benefits 
wi1l pressure 
the 
tech- 


nology of parallel processing 
to include microcomputers 


in an increasing 
number of computer applications. 
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Triple-bus 
architecture 
lets a 
single-board microcomputer's 
CPU operate at full speed 


while other system components share the main memory. 


The introduction 
of Intel's· iSBC 80/30 marks 
the 
beginning 
of the 
third 
generation 
of single 
board 


computer 
architecture. 
Two features 
separate 
the new 


microcomputer 
from second-generation 
single-board 
/LCs. The major 
one is a triple-bus 
architecture 
that 
supports 
a dual-port 
memory. 
As a result, 
the on- 
board CPU does not tie up the main system bus (Intel's 
Multibus) 
when 
using the memory. 
Moreover, 
with 
two ports, 
the 
memory 
becomes 
a global 
resource, 
accessible via the three buses from the on-board 8085A 
CPU as well as from remote CPUs and other external 
devices 
in multimaster 
schemes. 


In addition, the 80/30 contains two microprocessors: 


an 8085A acting as the master CPU and an 8041 single- 
chip microprocessor 
acting as a slave, or intelligent- 
I/O, 
processor. 


Jim Johnson, Project Leader, Craig Kinnie, Project Man- 
ager, and Mike Maerz, Marketing 
Manager, Intel Corp., 
Santa Clara, CA 95051. 


To appreciate 
the benefits 
of the 80/30's triple-bus, 


dual-port 
memory architecture, 
examine the following 


problem. Now that fully one fourth (16-kbytes) of the 
available 
memory 
space in a 64-kbyte 
/LC system 
can 
reside on a single-board 
/LC, the CPU must share these 
16-kbytes 
with 
other 
system 
components, 
such 
as 


direct-memory-access 
devices, discs and other proces- 


sors. What's 
the best solution-especially 
when, 
in 
many applications, 
16-kbytes is all the memory that's 
required 
by the whole system? 


Alternatives 
have 
problems 


The 
most 
straightforward 
way 
is 
a 
split-bus 


architecture, 
in which both the CPU and the system 
have equal access to the memory 
(Fig. 1a). While the 


system 
bus will be able to handle 
memory 
access 


efficiently 
from devices tied to it, it will be tied up 
by the CPU-so 
external 
operations 
not related 
to 
memory 
accesses 
will be hindered. 
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1. Microcomputer-bus organizations takes several forms: 
In a split-bus approach (a) the CPU and system have equal 
access to memory, but the CPU ties up the system bus; 
in a single-bus (b). the CPU encounters extra delays in 


A single-bus 
approach 
(Fig. 
Ib) is hampered 
by 
buffer 
and bus-intervention 
delays 
which 
limit 
the 
CPU's performance. 
And dual-bus 
architecture 
(Fig. 


Ie), while granting 
the CPU exclusive access, does not 
allow other bus masters 
access to the memory. 
Also 
dual-bus 
suffers 
from buffer 
delays. 


A triple-bus, 
dual-port 
architecture 
(Fig. Id) pro- 


vides the benefit of both single and dual-bus 
architec- 
tures: total system access and exclusive access by the 
CPU. But 
it also has 
its disadvantages: 
Dual-port 
architecture 
requires 
many buffers as well as access- 
arbitration 
logic. However, 
20-pin octal buffers 
in- 
troduced 
by several 
manufacturers 
don't 
take 
up 
nearly 
as much 
board 
space 
or cost 
as much 
as 
equivalent 
standard 
buffers. 
Since the octal buffers 
come in unidirectional 
or bidirectional 
forms-and 
at 
nearly 
the same cost-the 
three-bus 
approach 
used 
on the 80/30 actually 
takes 
only as many packages 
as the split-bus 
approach. 
Access arbitration 
is solved in the 80/30 with cycle 
status 
signals from the 8085A CPU. Instead of provid- 


ing equal access to the RAM from both the CPU and 
the system, 
the arbitration 
logic is designed 
to favor 
the CPU. By assigning 
the default state of the arbiter 


using the system bus. A dual-bus structure 
(c) also has 
buffer delays, and no system access to on-board memory. 
But a triple-bus (d) avoids all these problems. allowing 
total system access to memory. 


to the CPU, the logic anticipates 
a CPU memory access 
and reserves 
the memory 
until the cycle is complete. 


In addition, 
if an on-board CPU access is imminent, 


a reservation 
signal 
derived 
from 
the 
8085A CPU 


status 
signals, 
the ALE (address 
latch 
enable), 
the 
address, 
and the cycle status 
signals (SO, SI, IO/M) 


will hold off bus contention. 
As a result, the CPU can 


operate at full speed without tying up the system bus. 


Of course, this extra CPU performance 
cuts into the 


rest of the system's 
memory-access 
time. 
However, 
the penalty 
imposed 
by the arbiter 
is less than 
200 
ns-Iess 
than 
the time it would take a DMA device 


to regain control of the bus in the split-bus 
approach, 


where 
access must 
be interleaved. 


A bus hierarchy 


The three buses in the 80/30 hierarchy 
(Fig. 2) are 


an on-board bus, a dual-port 
(DP) bus and the Multi- 
bus 
(system 
bus). 
Innermost 
is the 
on-board 
bus, 


which connects the 8085A, all on-board 
I/O peripher- 
als and ROM. The next bus in the hierarchy, 
the dual- 
port 
connects 
a dual-port 
controller, 
I6-kbytes 
of 
dynamic 
RAM and a dynamic 
RAM controller. 
The 


RS232C 


COMPATIBLE 


DEVICE 


2. The full 80/30 one-board microcomputer is organized 
around 
its three buses: on board. dual-port, 
and the 
external-system Multibus. The main CPU,an 8085A, runs 


ON-BD 
16 K 
i$BC 201 


RAM 
DISKETTE 


CONTROLLEA 


DUAL 


PORT 


BUS 


RAM 


ADDRESSES 


32K-48K 


RAM 


ADDRESSES 


48K·64K 


3. The microcomputer's 
on-board memory may be ad- 
dressed independently by the on-board central processor 
and Multibus bus masters to increase the efficiency of 
usage of the total available memory space. 


USER 
OESIGNATED 


PERIPHERALS 


42 PROGRAMMABLE 


PARALLEL 
I/O 
LINES 


at 2.76 MHz, while an 8041A one-chip microprocessor 
serves as a peripheral 
controller 
or slave processor, 


running with a 2.6-ms cycle time. 


outermost 
bus, 
the 
Multibus, 
offers 
modules 
that 


permit 
either 
the expansion 
or addition 
of system 
resources. 


With 
the on-board 
bus, the 8085A communicates 


with its on-board I/O and ROM (or PROM, if desirable) 
and the dual-port 
bus. Since the on-board bus permits 
access to the I/O and ROM only from the 8085A, all 
I/O and ROM (up to 8-kbytes are the 8085A's private 
property). 
And as a result, 
the 80/30 can operate 
on 
its on-board bus while another 
Multibus 
master 
uses 
the Multibus, 
accessing 
data from the board's 
dual- 
port 
RAM without 
reducing 
processor 
speed. 


The dual-port 
(DP) bus contains 
16-k of read/write 


memory, 
implemented 
with 
Intel's 
2117 16-kbyte 


dynamic 
RAM and the 8202 dynamic 
RAM controller 


(DRC). The DRC interfaces 
the DP bus to the 16- 
kbytes 
of dynamic 
RAM, and 
provides 
an almost 
static-RAM 
type interface. It provides the system with 
multiplexed 
addresses, 
address 
strobes, 
and refresh 
control 
to the RAM, as well as refresh/access 
arbi- 
tration 
and acknowledges. 


The RAM on this bus can be accessed from either 
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the 
808SA on the 
80/30 
or the Multibus. 
Th.e DP 


controller 
arbitrates 
the RAM requests 
and performs 


the bus exchanges. 
The DP controller 
always leaves the DP bus under 


the control of the 8085A when it is not in use. This 
permits 
the 8085A to operate 
at maximum 
processor 


speed when controlling 
the bus, since there isn't any 


bus-exchange 
overhead. 
When the Multibus 
requests 


access to the DP RAM, the DP controller 
transfers 


control of the DP bus to the multibus, 
as soon as the 


DP bus is not busy. 
Once the Multibus 
transfer 
is 


complete, 
the DP bus is returned 
to the 8085A. 


Multiple 
communication 


The DP controller 
has 
two independent 
address 


decoders-one 
for decoding 
Multibus 
requests, 
the 


other 
for 80/30 requests. 
This not only permits 
the 


address 
space 
of the memory 
to be located 
in two 


different 
parts 
of memory 
(Fig. 3), it enables several 


80/30s to talk to each other over the Multibus, 
while 


sharing 
the same 
on-board 
address 
as seen by the 


8085A. Thus, one program 
can be loaded in any 80/30 


without 
relinking 
and 
relocating 
the 
software 
for 


execution. 
Each bus can communicate 
either within 
itself, or 


with the adjacent 
bus. Thus, the on-board bus cannot 


communicate 
directly 
with 
the multibus. 
However, 


when the CPU makes a bus request, 
the on-board and 


dual-port 
buses simultaneously 
determine 
if they can 


fulfill 
it. If the on-board 
bus can acknowledge 
the 


request, 
it does so, and the DP bus control 
is not 


required 
to determine 
if the DP bus can acknowledge 
the 
request. 
If the DP bus, 
not the on-board, 
can 


acknowledge 
the request, 
it does so, and the controller 


then lets the CPU use the bus. Thereafter, 
the RAM 


controller 
completes 
the operation 
and generates 
an 


acknowledge 
signal. 


If neither 
the on-board nor DP bus can fill the bill, 


the Multibus 
is solicited by the CPU. Since a bus can 


only communicate 
with an adjacent 
bus, the on-board 


bus must 
request 
the DP bus to communicate 
with 


the Multibus 
via the DP controller. 
The on-board bus 


will retake control of the DP bus only after the request 
to use the Multibus 
is granted. 
This prevents 
lockout 


problems 
with the DP bus, where the CPU requests 


the Multibus 
when 
it is controlled 
by another 
bus 


master 
accessing 
the DP RAM. 
How the 80/30 performs 
is directly 
related 
to how 


many 
buses 
it must 
use to complete 
a requested 


operation. 
The on-board 
bus always operates 
at max- 
imum processor 
speed. The DP bus operates 
at max- 
imum only if it hasn't been busy and a memory refresh 
cycle was not in process. The processor 
speed when 


the Multibus is used depends on bus overhead involved 
and the type of module 
requested. 
The 80/30 boasts 
more than 
a three-bus 
architec- 


ture. 
For one thing, 
its I/O is designed 
to interface 


to 
a 
wide 
variety 
of 
external 
devices, 
including 
switches, 
motor 
drives, 
bistable 
sensors, 
displays, 


The iSBC 80/30 uses the latest 
LSI components 
to 


obtain 
the highest 
performance 
of any Intel 
single- 
board 
computer. 
Built 
on a 6.75 x 
12-in. board, 
it 


contains 
the 
following 
features: 
• 8085A central 
processor 
operating 
at 2.76 MHz. 


• 16-kbytes 
of dual-port 
RAM using Intel's 
new 16- 


kbyte 
dynamic 
RAMs and 8202 dynamic 
RAM con- 


troller. 
• Sockets 
for 2, 4 or 8-kbytes 
of ROM using Intel's 


2758, 
2708, 
2716, 
or 
2332 
EPROMs 
or 
ROM 
re- 


placements. 
• A socket 
for Intel's 
8041A/8741A 
universal 
pe- 


ripheral 
interface 
(UP!) 
having 
18 software-con- 


fiv;urable 
I/O 
lines 
with 
sockets 
for drivers/termi- 
nators. 
• A programmable 
serial-communication 
channel 
with RS-232 interface 
and programmable 
baud rate. 


• Multibus 
control 
logic 
which 
allows 
up 
to 
16 


masters 
to share 
the system 
bus. 
• 12 vectored 
priority 
interrupts. 
• Two programmable 
16-bit BCD or binary 
internal 


timers. 


keyboards, 
printers, 
teletypewriters, 
communicator 


modems, 
cassettes 
and other 
computers. 
This ver- 


satility 
is provided 
with LSI programmable 
devices 


such as Intel's 8255 programmable 
parallel I/O device, 


8251A programmable 
communication 
channel, 
8253 


interval 
timer, 
8259 
interrupt 
controller, 
and 


8041A/8741A 
universal 
peripheral 
interface 
(UPI). 


The 
slave processor 


The ability to interface 
this wide variety of external 
devices is facilitated 
by the 8041A/8741A 
UPI (Fig. 


4), which can be added 
to the 80/30. The UPI is a 


complete 
single-chip 
microcomputer 
which acts as a 


peripheral 
to the 8085A. It is completely 
user-pro- 


grammable 
with l-kbyte 
of ROM (8041A) or EPROM 


(8741A) memory for data storage. The UPI allows you 
to fully specify your control algorithm 
in the peripher- 


al chip without 
relying 
on the 8085A. Devices such 


as printer 
controllers 
and keyboard 
scanners 
can be 


completely 
self-contained, 
relying 
on the 8085A only 


for data 
transfers. 


The UPI is a powerful8-bit 
CPU with a 2.6-ms cycle 


time and an instruction 
set optimized for bit manipu- 


4. The 8041A/8741A single·chip microcomputer (UPI-41) 
has its own on-chip 
ROM and RAM and can be pro- 
grammed to perform various peripheral control functions. 


I 
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5. The UPl's two data registers are organized so that the 
8085A CPU can write in just one register and read from 
the other. As a result, the two registers appear as one 
register to the main 8085A CPU. 


lation 
and 
I/O 
operations. 
It 
contains 
an 
8-bit 
counter/timer, 
buffers 
to 
communicate 
with' 
the 


8085A, and two 8-bit programmable 
I/O ports, which 


can 
be customized 
by software 
or by plugging 
in 
suitable 
line drivers 
or terminators 
into sockets. The 


UPI also has two input bits that 
it can test directly. 
An RS-232 driver 
and receiver 
on the 80/30 permit 
the UPI to be programmed 
as a simple 
serial-com- 
munication 
channel. 


Interfacing to the on-board bus 


The UPI 
interfaces 
asynchronously 
with 
the on- 
board 
bus using two data 
and two status 
registers. 
The UPI's 
two internal 
data registers 
appear 
to the 


8085A as only one register, 
since one data register 
can 


be written 
into only by the UPI and read only by the 


8085A, and the other can be written 
into only by the 


8085A and read by the UPI (Fig. 5). This is done to 
prevent 
the two CPUs from simultaneously 
writing 


into a data 
register. 


The 
UPI 
can 
communicate 
with 
the 
8085A by 


loading 
a data 
register 
and 
then 
returning 
to its 


previous control task. The 8085A can periodically 
poll 
the UPI status 
port for the valid-read 
(VR) flag, which 
is set in hardware 
when the UPI writes 
to its data 


port,.or the UPI can generate 
an interrupt 
to the 8085A 


via an I/O bit that can be programmed 
to be the VR 
flag. 
Once the 8085A determines 
the VR flag is true, 
it 


can transfer 
the data 
to its own memory 
without 


disturbing 
the 
UP!. 
The VR flag 
is automatically 


cleared after the data are transferred. 
Similarly, 
when 
the 8085A transfers 
data to the UPI, a valid output 
(VO) flag 
is set 
and 
an 
interrupt 
to the 
UPI 
is 


generated 
(if enabled) 
automatically. 
Once the UPI 
transfers 
the data, the VO flag is cleared. The VO flag 


can also be programmed 
to a port bit for generating 
interrupts 
to the 8085A to indicate 
that 
the transfer 
is complete. 


An extensive interrupt system 


The 80/30 provides 12 vectored 
priority 
interrupts, 


four 
of which 
are handled 
directly 
by the 8085A's 
interrupt-processing 
capability 
and routed 
to fixed, 


unique memory 
locations. The remaining 
eight levels 
are handled 
via the 8259A programmable 
interrupt 
control1er 
(PIC), which generates 
a unique 
memory 


address 
for each level. These addresses 
are equally 


spaced 
at intervals 
of four or eight (software-selec- 


table) bytes. This 32 or 64-byte block may be located 
to begin at any 32 or 64-byte boundary 
in the 65,536- 
byte memory 
space. A single 8085A jump instruction 
at each of these addresses 
then provides 
the linkage 


to locate each interrupt-service 
routine independently 


anywhere 
in memory. 
The PIC provides 
a selection 
of four 
priority 
algorithms 
so that 
the 
manner 
in 
which real-time 
requests 
are processed 
may be con- 
figured to meet the requirements 
of the system under 
design. 


The 80/30 also has two 8253-based programmable 


16-bit BCD and binary 
timers/event 
counters, 
which 


can be used for a variety 
of functions. 
Both timers 


may be set to act as a rate 
generator 
(divide-by-N 


counter), 
a square-wave 
generator, 
a programmable 


retriggerable 
one-shot, 
or one of the timers 
can be 


jumper-selected 
as an event counter. 
In addition, 
an 


interrupt 
can be generated 
when a time interval 
has 


expired 
or when 
a specified 
number 
of events 
has 
occurred. 


To see how useful 
the 80/30 
can be, consider 
a 


supervisory 
control/monitoring 
system (Fig. 6) using 


an Intel iSBC 80/30 single-board 
computer, 
iSBC 201 


diskette 
controller, 
and iSBC 732 analog input/output 
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6. 
In this application example, 
the 80/30 forms 
the heart 


of a remote 
data-acquisition 
system. 
By taking 
advantage 


of the one-board 
microcomputer's 
dual-port 
memory 
and 
universal 
peripheral 
interface, 
the 
system 
achieves 
a 


combination 
of attractive 
cost 
and 
efficiency. 


board. 
Here local commands 
and process-status 
sig- 


nals 
are given 
and 
displayed 
on a CRT, which 
is 


interfaced 
via 
the 
iSBC 
SO/30 resident 
UPI 
and 


RS232C components. 
Process variables 
are converted 


from 
analog 
to digital 
using the analog 
I/O board. 


Control variables 
are passed over the Multibus 
from 


the SO/30 to the 732, where they are converted 
from 


digital 
to analog. 


System data are logged on two diskettes, 
which are 


controlled 
by the 201. The controller 
board's on-board 


DMA interface 
accesses the SO/30's dual-port 
memory 


and stores 
the data 
on one of the floppy discs. 


At the end of the day, a remote 
host 
processor, 


interfaced 
to the SO/30 via a modem 
(through 
the 


SO/30's S251A and RC232C circuits) 
can request 
all 


or part of the diskette-resident 
data. Here, the SO/30 


uses its on-board 
dual-port 
memory 
as a data buffer 


for transfers 
to the host. 


Intel's RMX/SO real time executive, disc-file system 


and 
analog 
drivers 
provide 
the 
majority 
of 
the 


system's 
software .•• 


Note: Multibus and iSBC are registered trademarks 
of Intel Corp. 


ARTICLE 
REPRINT 


Dual-port RAM hikes throughput 
in inpuVoutput controller board 


On-board random-access 
memory, accessible from system bus, 


makes input! output controller subsystem look like 
just another memory board to the host microprocessor 


o Input/output 
controllers 
based on microprocessors 


step up throughput 
in microcomputer systems by reliev- 


ing the host processor of tedious, time-consuming control 
tasks-and 
a new design concept 
that 
increases 
the 


processing capability of this subsystem promises to hike 
throughput 
even more. It will cut the host intervention 


needed to transfer data and to run the controller. 


In this configuration, all communications 
between the 


host processor and the controller are handled through a 
section of dual-port memory that resides in the controller 
subsystem. This setup allows more efficient transfer of 
large blocks of data from the 110 device to the system 
without contention over access to the system bus. It also 
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simplifies interprocessor 
communications 
because 
the 


subsystem controller appears to the host processor sim- 
ply as an additional 
RAM board. 


Although this concept allows the subsystem to remain 


dedicated 
to its 110 control function and to assume a 


subservient 
role to the 
host processor, 
it has 
more 


processing 
power 
than 
previous 
generations 
of such 


controllers. 
Hence it has been dubbed the intelligent- 


slave concept by Intel, which applies it in the iSBC 544 
intelligent communications controller. 


The new subsystem architecture 
is divided into three 


major sections: dedicated 
110, dedicated computer, 
and 


dual-port memory (Fig. 1). The dedicated input/output, 


1. Heart 
of memory. 
New controller 
archi- 


tecture includes the dedicated 
inpull output 


circuitry and dedicated processor 01 an Intel- 


ligent peripheral 
controller, 
but its heart is 


the duai-port random-access memory. 
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2. Performance 
advantage •. In adding a real-time task to an existing real-time system, the load on the system bus Is significantly reduced 
over the traditional multitasking approach (a) or the intelligent controller approach (b) by the intelligent-slave controller approach (c). 
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3. The 544. Based on the 808SA microprocessor 
with 4 kilobytes 
of PROM and 16 kilobytes 
of RAM, the subsystem 
is designed as a 
communications 
controller with four synchronous/asynchronous 
buffered serial I/O channels. and a 1o-blt parallel I/O interface. 


The concept of a dual-port read-write memory used in the 
iSBC-544 communications board is also employed in 
another new Intelproduct: its latest single-board comput- 
er, the iSBC-80/30. A dual port makes the 80/30's 
random-access memory directly accessible by the on- 
board 8085A central processing unit via internal busing 
without tying up the external system bus, the Multibus.At 
the same time, it also makes the RAMdirectly accessible 
by any other boards, like direct-memory-access control- 
lers or other one-board computers that may be tied to the 
Multibus. 


Moreover, the 80/30 
adds its dual-port bus to the 


earlier iSBC computers' pair of buses: an internal bus, 
which hooks the CPU to peripheral chips and read-only- 
memory program storage and the system bus, over which 
the CPUand other boards communicated withRAM.Eight 
bits wide, the new bus is connected to a pair of buffer 
registers that coordinate, thus making the RAMaccessible 
either by the internal bus or the system bus. 
The objective is throughput: the CPU has priority in 


access to the on-board RAM.But since the access is not 
over the Multibus system bus, which might be tied up, 
there is no waiting. From the viewpoint of other system 
boards, the system bus is accessible a greater percentage 
of the time. 


Withthe incorporation of 16 kilobytes of memory on the 


80/30, Intelhad littlechoice but to move to the dual-port, 
triple-bus architecture. The reason is that few system 
designs require more than 16 kilobytes, so in many appli- 
cations all boards will be demanding access 
to the 


80/30's 
memory over the Multibus.The CPU had better 


have priorityto its RAM,through its own private line, lest 
the queue for the system bus bog down throughput. 


The 80/30 also packs lots of extras, in addition to the 


total 16,384 bytes of read/write memory built with 2116 
16-K dynamic RAMs. A pair of ROM sockets provide 
4,096 bytes of program storage iffittedwith 16-Kerasable 
programmable read-only memories like the 2716. When 
pin-compatible 32-K erasable 
PROMs are 
available, 


program storage can be extended to 8 kilobytes. 


Also on board is a socket for Intel's universal peripheral 


interface 
chip, the 
8041 
(or 8741 
erasable-PROM 


version), which can function as a slave processor to drive 
peripheral 
devices. 
An 8251A 
universal 
synchro- 


nous/ asynchronous receiver/transmitter is included for 
serial communications, and the 80/30 also boasts three 
16-bit programmable 
timers. The 24 programmable 


input! output lines are brought out to sockets that accept 
quad line-driversor -terminators for interfacing. 


R8yC8pece 


consisting 
of the 
necessary 
peripheral 
chips, 
timers, 


buffers, 
and 
interface 
integrated 
circuits, 
tailors 
the 


controller to the application's 
110 requirements. 
The dedicated computer consists of a general-purpose 


microprocessor, 
electrically 
programmable 
read-only 


memory, dedicated 
RAM, timers, interrupt logic, and the 


decode and chip-select logic. The size and speed of the 
central-processing 
unit can be tailored 
to match 
the 


requirements of the dedicated 
110 section. 
The dual-port memory is the heart of the architecture 


and sets it apart from traditional 
approaches to intelli- 


gent 
controllers 
and 
multiprocessing. 
Passing 
all 


commands and data between the system and the control- 
ler's processor through this memory offers a number of 
significant advantages. 
First, the dedicated 
computer's 
performance 
can be 


optimized for its applications. Its software always oper- 
ates at full speed, since all required 
memory and 
I/O 


resources are immediately accessible on the board, with- 
out indeterminate 
delays caused by other system activity 


on the bus. This accessibility is especially important 
in 


real-time 
systems, 
since 
it 
allows 
the 
controller's 


performance to remain constant even though system bus 
activity may change. 
Secondly, the architecture 
presents a consistent and 


convenient interface between the host CPU and all the 
controllers in the system, regardless of function. Because 
the controllers' dual-port 
RAM looks to the host CPU like 


just another location in system memory, the hardware 
and software problems associated with connecting multi- 
ple processors 
together 
are 
reduced 
to interfacing 
a 


number of identical intelligent memory locations. 
Also, the architecture 
offers a degree of protection for 


the data in memory. The subsystem computer and soft- 


ware can only alter that portion of system memory that 
resides in its own dual-port memory section. In contrast, 
traditional 
intelligent 
controllers 
have access 
to the 


entire system RAM and, should a malfunction occur, can 
destroy all of that memory. 


Sy.tem performance advantage. 


Because all processing assigned to the new controller's 


CPU takes place off the system bus, its architecture 
offers 


important performance advantages to the system. These 
advantages come from the appearance 
of the processed 


data blocks in system memory without consuming any 
system resources or bus time 
The advantages 
of this approach 
are best demon- 


strated by comparing it to alternative means of adding a 
real-time task to an existing real-time 
system. In this 


case, the new task requires additional 
CPU, memory, and 


110 resources. 


The traditional 
multiprocessor 
approach 
of Fig. 2a 


expands 
CPU 
resources in one of. two ways: software 


utilization of reserve capacity in the existing processor, 
or adding another processor. In either case, memory and 


110 increments generally will be required. 


The primary disadvantages 
of this approach 
are the 


increased 
complexity 
of the system software 
and the 


increased load on the system bus. Both will slow the 
existing real-time 
system unless it has been designed 


with adequate reserve. The system bus must also provide 
sufficient capacity 
for the incremental 
memory-execu- 


tion and data-transfer 
operations. 
This additional 
bus 


load will also require that the primary real-time task can 
tolerate CPU delays due to bus contention. 


The 
intelligent-controller 
approach 
of Fig. 2b has 


gained widespread use since the advent of the micropro- 
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4. Memory m8pplnll. The variable system memory addresses are 
always mapped 
into the on-board 
address of BOOOHEX.providing 


software independence for the subsystem and the host. 


cessor. This approach combines the CPU and I/O incre- 
ments onto a single module that usually includes direct- 
memory-access transfer logic. In some cases the execu- 
tion memory for the CPU is included. 
This approach 
lessens the bus-loading problem since 
the I/O data transfers and some memory-execution cycles 
take place off the system bus. However, 
both cpus' 


programs 
will 
have 
to 
tolerate 
delays 
caused 
by 
increased bus contention. Increased software sophistica- 
tion is the primary disadvantage of this approach, much 
as with the multiprocessing approach of Fig. 2a. 
The 
intelligent-slave 
approach 
of Fig. 
2c can 
be 


viewed as a logical extension to the intelligent-controller 
approach. 
Combining the CPU. I/O, and memory incre- 


ments creates a single module that has a minimal impact 
on the existing system software and bus loading. What's 
more, the subsystem can operate at full capacity without 
regard to other system activity. It can be programmed 
outside the primary system and then added with minimal 
impact on the system software or performance. 
A limitation 
of the approach 
is the inability of the 


subsystem to transfer data into portions of the system 
memory space that reside off its board. This problem is 
minimized by the ability of the controller's 
RAM to serve 


as a substantial 
portion 
of the entire 
memory 
space 


addressable 
by the system. In this light, the on-board 


processor can be viewed as having a 
DMA capability 


limited to a portion of the system's address space. 
In a system with more than one of the new controllers, 
the system 
CPU handles any data that must be trans- 


ferred from one to another. 
Applications 
involving the 


transfer of large blocks of data would be best served by a 
central block-transfer device elsewhere on the bus. 


The advantages offered by the new approach 
in this 


example of adding onto an existing system are just as 
applicable 
to 
a 
ground-up 
design. 
This 
modular 


approach 
to 
configuring 
real-time 
multiprocessing 
systems simplifies hardware and software design, as well 
as system integration. 


While the primary design objective of the new archi- 
tecture is operation in a multiprocessing 
system, it can 


provide 
significant 
utility 
as 
stand-alone 
processors. 


Thus these controllers 
incorporate 
a second mode of 


operation called the limited bus-master mode. 


In this mode of operation the new controller can be 


used like a single-board computer 
as long as it is the 
system's only master of the bus. It can be connected to 
standard memory or I/O expansion boards to enhance its 
capability. 
It can even be used to drive other 
such 
controllers as long as they are used in the subsystem 
mode. This dual operational 
mode will allow the new 
controllers to serve a broad range of applications. 


Communication. 
fir.t 


Communications 
applications 
present 
complex 
pro- 


cessing requirements 
and an inherent real-time nature, 


so it is logical that a communications 
processor be the 


first of these new controllers to be marketed. The iSBC 
544 intelligent communications controller can serve as a 
flexible front end to an iSBC system or as a cost- 
effective stand-alone processor configured as a terminal 
cluster or line concentrator. 
Its design (Fig. 3) incorpo- 


rates an 8085A CPU, 16 kilobytes of dual-ported dynamic 


RAM, 
4 kilobytes 
of 
PROM, 
programmable 
interrupt 
control, three interval timers, four programmable 
baud- 
rate 
generators, 
four 
synchronous/asynchronous 
buf- 


fered serial I/O channels, and a ID-bit parallel interface 
compatible with a Bell 801 automatic calling unit. 


The dual-port memory block basically consists of the 


16-kilobyte bank of random-access 
memory, which is 


accessible from either the system bus or the on-board 
processor through the dual-port controller. This memory 
block provides the primary 
means of communication 


between the system and the on-board 8085A. The port to 
the memory, which looks to the system bus like any other 
RAM card belonging to the system, features full 2D-bit 


addressing and a typical access time of 600 nanoseconds. 
The interface's address-decode logic allows switching 


of the base address of the iSBC 544 to any 4-kilobyte 
boundary in the host system's address space. In addition, 
the user may reserve 8, 12, or 16 kilobits of the 544's 
memory for use by the on-board processor only. This 
reserved memory is not accessible from the system bus 
and does not occupy any system address space. The only 
restriction is that all of the unreserved memory reside in 
the same 64-K address page of the system memory. 
This memory division can be a significant advantage 


in large 8-bit microcomputer systems. Only that portion 
of the controllers' memory needed to pass data between 
cpus 
must 
be made 
accessible 
to the 
system. 
The 


remaining 
buffer 
and 
execution 
memory 
does 
not 


consume any system address space. 
The net result is an increase in the system's overall 


memory capacity. For example, a microcomputer system 
that would usually be limited to 64 kilobytes of memory 
has a total memory capacity of over 190 kilobytes when 
driving seven 544s. 


Addre•• map. and interrupt. 


To the on-board 
processor, the base address of its 


memory is fixed at 8000HEX. Furthermore, 
all on-board 


addresses are fixed, so that multiple 544s operating on 
the same system bus can be running identical programs 
regardless of their base address on that bus. This capa- 
bility necessitated 
the address-mapping 
logic to trans- 


form addresses from the system bus into the equivalent 
in the 
on-board 
address 
space 
starting 
at 
location 


8000HEX(Fig. 4). 
The address-mapping 
logic also implements the f1ag- 


interrupt 
feature. 
It provides an interrupt 
to the on- 


board processor whenever a byte is written into the 544's 
base address from the system bus, and a read from the 
on-board processor to the base address clears the inter- 
rupt. Since each 544 in a system has a different base 
address 
in that 
system's 
RAM, it also has a unique 


interrupt. This flag-interrupt capability is a key element 
in establishing 
a protocol for communications 
between 


the host CPUand the subsystems' processors. 


The dual-port control logic is responsible for resolving 


contention over access to the memory and is designed to 
optimize the performance of the subsystem CPU.Unless 
the system bus has initiated a memory cycle befote the 
on-board processor requests memory, that CPU runs at 
full speed. The maximum delay that can be encountered 
is one memory 
cycle. The 
arbitration 
logic actually 


reserves the memory for the on-board processor before it 
generates the necessary commands. This advance reserv- 
ing guarantees 
that the on-board CPU will suffer mini- 


mum intervention from system bus accesses. 


When the iSBC 544 is used in the stand-alone limited 


bus-master mode, the dual"port logic is disabled and the 
bus interface buffers are turned around to drive onto the 
bus. This reversal allows the on-board central-processing 
unit access to the memory of other subsystems or I/O 
expansion boards on the system bus. 
The dedicated computer is built with an 8085A CPU 


operating at 2.76 megahertz, between 2 and 4 kilobytes 
of PROMand ROMSor 8 kilobytes of ROMusing 2332 


5. Communication 
•• 
ppllclltlon 
•. Two typical applications 
of the 
new Isse 544 would be as a front-end communications 
processor to 
a microcomputer 
system and as a remote concentrator 
to a series of 
point-to-point 
or mUltidrop connected terminals. 


mask-programmable 
parts, 256 bytes of static RAM,two 
16-bit and 
one 
14-bit 
interval 
timers, 
and 
a 
8259 
programmable interrupt controller for individual receive 
or transmit interrupt inputs for each serial port. 


Special command-decode 
logic was added to the CPU 
to allow it to operate at maximum speed independent of 
other system activity. There are 21 sources of interrupt 
on the 544, including the separate transmit 
and receive 
interrupts for each port and separate timer interrupts. In 
addition to receiving an interrupt 
from the system, the 
544 can also send an interrupt to the system bus via the 
8085A's serial-output data line. 


Since this controller is intended for communications 
applications, latched interrupts 
are provided directly to 
the CPUfor loss of carrier and ring indicator for all four 
I/O ports. The ring-indicator and carrier-detect 
lines car 
also be monitored through the parallel port. 


Dedicated I/O 


The dedicated-I/o 
section of the 544 provides a high 
degree of flexibility and programmability. 
This results 
primarily 
from the inclusion of four 8251A universal 


synchronous/asynchronous 
receiver/transmitters. 
These 
devices are programmable 
for synchronous or asynchro- 


nous mode, character 
size, parity 
bits, stop bits, and 
baud rates. Data, clocks, and control lines are buffered 
with RS-232-C-{;ompatible 
drivers and receivers to four 
26-pin card-edge connectors. Each port is configured as 
a data-terminal 
interface, 
but may be converted 
to a 
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I. From alave to m.ater. In its stand-alone mode, the 544 can operate as a bus master and be configured as an intelligent terminal controller 
connecting dumb terminals to a data link (a) or as a peripheral controller connecting RS-232-G-compatible 
units to the terminal (b). 


data-set 
interface 
by changing 
a single jumper-plug 


assembly. 
The 
ports support 
most RS-232-C 
signals 
(those that are listed in the table). 


A programmable 
baud-rate generator is also provided 


for each port. The range of baud rates available is 75 to 
56 kilobits per second. The generators are implemented 
with 8253 programmable interval timers, which receive a 
jumper-selectable 
input frequency of 1.84 or 1.23 MHZ. 
In addition, 
one of the cpu's 
interval 
timers can be 


converted to baud-rate 
operation and jumpered 
to any 


port to provide it with split-speed operation. 
The 
544 also provides 
a parallel 
port 
with 
four 


RS-232-C 
buffered 
input 
lines 
and 
six 
RS-232-C 


buffered output lines. This port is configured to interface 
to most automatic 
calling units but may be used as a 


general-purpose 
110 port. It is implemented with an 8155 


programmable peripheral interface that also provides the 
256 bytes of static RAM and the 14-bit timer. 


Applications 


A likely common use of the 544 as a subsystem is as a 


front-end processor or [erminal multiplexer 
(Fig. 5) in 


an iSBC system. The 544 performs all communications- 
related functions such as format control, code conver- 
sion, data-link control, error checking, data compression, 
and protocol management. 
It can handle multiple proto- 


cols, line speeds, and data formats. 


All the system processor sees are the processed data 


blocks that 
appear 
in system memory. An automatic 


dialer could be added to provide a dial-up connection t.o 
a host processor or network. 
Also shown in Fig. 5 is another 544 used in its limited 
bus-master mode as a remote concentrator 
and terminal 


controller. The line and memory capacity of the remote 
concentrator 
can be increased by the addition of stan- 


dard iSBC memory and I/O expansion boards. 


The intelligent-terminal 
controller shown in Fig. 6a is 


a prime example of a 544 used in the stand-alone mode. 
It can connect one or more dumb terminals to a data link 
and provide the necessary buffering, code conversion, 
and data-link control. It could also connect a terminal 
that happens to communicate in a different protocol to a 
new network or to more than one network. 


The iSBC 544's multiple serial lines do not have to be 


used for communications. 
They can also be used to 


connect RS-232-C~ompatible 
peripherals to the termi- 


nal (Fig. 6b). In this configuration, the 544 can provide 
message editing and formatting, bulk storage, and hard- 
copy output. 


As this 
last 
application 
suggests, 
the 
544 is the 


vanguard of a family of intelligent 
110 controllers that 


will add tremendous increases in throughput 
and versa- 


tility to the iSBC line of single-board computers. 
The 


basic architecture 
will simplify the task of developing 


multiprocessing 
hardware 
and software 
solutions that 


will overcome throughput limitations. 
0 
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16-bit single-board computer 
maintains 8-bit family ties 


Three-bus 8086-based 
board addresses a megabyte, 


communicates 
over expanded system bus 


o For the first time ever, 8- and 
16-bit single-board 


computers 
can brainstorm 
over the same system bus. 


The iSBC 86/12 
16-bit SBChas been designed to work 


intimately with its predecessors, the iSBC 80 family of 
8-bit boards. What's in it for the user? Design flexibili- 
ty-8-bit 
designs can be enhanced to 16 bits, developed 


software can be transported 
and, beyond that, 8- and 


16-bit devices can be mixed in multiprocessing configu- 
rations. Several features make these options possible: a 
16-bit CPUand instruction set designed for 8-bit compat- 
ibility; greatly 
expanded 
memory 
resources; 
and 
an 


extension of the Multibus specifications. 
At the heart of the iSBC 86/12 
is a 16-bit, high- 


performance 
metal-oxide-semiconductor 
8086 
central 


processing unit that operates at 5 megahertz. 
Because 


the 8086 instruction set is a superset to that of both the 
8080A and 8085A 8-bit processors, the CPUcan execute 
the full set of 8080A/8085A-type 
8-bit instructions plus 


a new set of 16-bit instructions. Thus, programs gener- 
ated for 8-bit-cPU systems can easily be upgraded to run 
on the iSBC 86/12 
using the software tools available 


with the Intellec microcomputer 
development 
system. 


Programs 
written 
in 
Intel's 
high-level 
programming 


language, PLlM, can be executed. on both iSBC 80 and 
iSBC 86 products, preserving the software investment in 
8-bit systems as a user moves into 16-bit applications. 


Other 
features of the 8086 CPU are signed 8- and 


16-bit arithmetic 
(including multiply and divide), effi- 


cient interruptible 
byte-string operations, and improved 


bit manipulation. Furthermore, 
the 8086 provides mech- 


anisms for reentrant 
code, position-independent 
code, 


and dynamically relocatable programs. 


This enhanced processing power is supported by the 


largest memory ever offered on a CPU board (Fig. I). 
Memory address space has been extended over the iSBC 
80 series to one million bytes. Up to 16 kilobytes of 
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1. What 
a board. 
The iSBC 86/12 
has 32 kilobytes 
of RAM and room 
for 
16 kilobytes 
of ROM. The 5-MHz 8086 CPU executes 


8080A/8085A-type 
as well as 16-bit instructions. including multiply and divide. Address space has been increased to a megabyte. 
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r----------------~~~~~~ 


~ 
~ 


INTERRUPT 
SELECTE 
R 
(JUMPERS) 


2. LSI+SBC=88/12. 
A number of programmable 
LSI devices take credit for the power and flexibility 
of the iSBC 66/12. 
Note their 


interconnection 
to the three-bus hierarchy. When the 6066 requests a resource. the system bus is used only as a last resort. 


read-only memory can be installed on the iSBC 86/12 
itself. 
Furthermore, 
an 
additional 
32 kilobytes 
of 


dynamic random-access 
memory with on-board refresh 


may be accessed independently 
by the 
CPU or by the 


system bus (Multi bus). 
Like the'iSBC 80/30, the 86/12's 
RAM has dual ports 


to extend its use off board for access by other Multibus 
masters, including single-board computers, direct-memo- 
ry-access devices, and peripheral controllers [Electronics, 
Aug. 17, p. 109]. All memory operations on the board 
occur independently of the Multibus, freeing it for exter- 
nal parallel 
operations. 
For applications 
that 
require 


data integrity at all times, a separate bus supplies power 
to the RAM and support logic via the edge connector. An 
auxiliary power source energizes the RAM in the event of 
power failure. 


Multibus-the 
new look 


To exploit the greate~ performance 
of the 8086 CPU 


and simultaneously make the iSBC 86/12 fully compati- 
ble with the iSBC 80 family of 
SBCS 
and expansion 


products, the Multibus specification has been extended 
to support 20 bits of address and 16 bits of data. The 
control lines, too, have been expanded to direct 8- and 
16-bit data transfer over the system bus. These improve- 
ments enable the iSBC 86/12 to address directly a full 
one megabyte of system memory, access data in 8- or 
16-bit word lengths, and recognize and acknowledge a 
variety of interrupts. 


Address space has been enlarged to' 1 megabyte by 
adding four address lines, AID-A". Next, 8- and 16-bit 


data operations have been defined to permit both types 
in the same system. This is done by reorganizing 
the 


memory modules, adding one new signal and redefining 
another. 
The memory is divided into two 8-bit data 


banks, which form a single 16-bit word. The banks are 
organized such that all even-byte-addressed 
data is in 


one bank (Do-D,) and all odd-byte-addressed 
data is in 
the other bank (D,-DF). 
A new bus-address signal has 


been defined to control the odd-byte bank called byte 
high enable 
(BHEN) 
during 
16-bit operations. 
When 
active, BHEN enables the high byte of the data word from 
the addressed boards on the D,-DF Multibus data lines. 
Ao controls 
the even byte bank and, 
when inactive, 


enables the low byte of the data word on the Do-D, 
Multibus data lines. All word operations must occur on 
an even-byte-address 
boundary 
with 
BHEN 
active for 


maximum 
efficiency. 
(Ao 
is 
inactive 
for 
all 
even 


addresses-see 
the table.) Word 9perations on odd-byte 


boundaries will be converted to 2-byte operations by the 
8086, one for low-byte, one for high-byte. Byte opera- 
tions can occur in one of two ways. The even bank is 
accessed when BHEN and Ao are both low. This puts the 
data on Do-D,. To access the odd bank (normally placed 
on D,-DF during a word operation), a new data path has 
been defined. The active state of Ao and the inactive 
state of BHEN are used to enable a swap-byte buffer, 
which places the odd data bank on Do-D,. This permits 
an 8-bit master access to both bytes of the data word 
while controlling only Ao. Ao therefore specifies a unique 
byte and is not part of the word address, since all word 
operations are on even-byte boundaries. 


The iSBC 86/12 
owes much of its flexibility to program- 
mable large-scale integrated devices. An 8255A peripher- 
al interface chip provides 24 programmable I/O lines that 
may 
be tailored 
to 
the 
customer's 
needs 
by simply 
programming the device for input, output, or bidirectional 
modes with or without handshaking abilities. In conjunc- 
tion with the 8255A's 
configuration the user may then 


select appropriate line drivers and terminators for the I/O 
lines that can be inserted into sockets on the iSBC 86/ 12 
board. 


An 8251A universal synchronous/ asynchronous receiv- 


er/transmiller 
is included to provide an RS-232-C inter- 


face for serial communication with other computers, RS- 
232-C-type peripherals (casselle tape, modems, etc.) or 
cathode-ray-tube 
terminals. The 8251A enables the user 


to customize the communication link. Synchronous/asyn- 


chronous mode, data format, control character format, 
parity and baud rates from 75 to 38.4 kilobauds are all 
under program control. 


For system timing functions an 8253 programmable 


interval timer provides two programmable timers, each of 
which may be used as a square-wave generator, retrigger- 
able one-shot multivibrator or as an event counter. 


The interrupt structure of the iSBC 86/12 
encompasses 


nine levels with vectored priority. Eight of these levels are 
handled by an 8259A programmable interrupt controller 
chip, 
which 
may 
be 
configured 
for 
different 
priority 


processing modes in accordance 
with the application. 


One nonmaskable interrupt is available to immediately 
alert the CPU to catastrophes like a power failure, in which 
case the CPU can branch to an appropriate 
routine in 


memory to effect an orderly system shut-down. 


SWITCH- 
SELECTABLE 
ADDRESS 
DISPLACEMENT 
(Y 
PARAMETER) 


JUMPER- 
01FFF 
SELECTABLE 


SYSTEM 
03FFF 
128-KllDBYTE 


SEGMENT 
(X PARAMETER) 
05FFF 


NO 
ACCESS 
07FFF 


EOOOO - 
FFFFF 


07FFF 


AOOOO - 
BFFFF 
06000 


80000 - 9FFFF 
16 K 


60000 -7FFFF 
24 K 
11FFF 
04000 


4סס oo - 5FFFF 
32 K 
13FFF 
02000 


20000 - 3FFFF 
15FFF 
8K 


17FFF 
00000 
00000 - 1FFFF 


lBFFF 
00000 


1DFFF 


1FFFF 


3. RAM, ple•• e. The 808S's view of on-board memory is fixed from zero to 07FFFH. When an outside master accesses this space, the DP 


controlier performs the translation. Here, locations OSOOOHto 07FFFH are available to another master by addressing CAOOOHto CBFFFH. 


Since all 8-bit accesses via Multibus 
are done on the 


lower byte of the data word, the iSBC 86/12 
can access 


8-bit 
memory 
or 110 devices from 
the system bus. This 


makes the 
iSBC 
86/12 
compatible 
with 
all 
iSBC 
80 


Multibus 
modules. 


More interrupts, 
too 


The iSBC 
86/12 
expands the previous Multibus 
defi- 


nition 
of interrupts 
by creating 
two distinct 
types: non- 


bus-vectored 
(NBVI) 
and bus-vectored 
(BVI) 
interrupts. 
Each Multibus 
interrupt 
line can be individually 
defined 


through 
software 
to be a BVI or 
NVBI. 
Using 
BVIS, the 


interrupt 
capability 
of 
a 
Multibus 
system 
can 
be 


increased to 64 bus-vectored-priority 
interrupts. 


Using NBVIS, a slave module activates an interrupt 
line 


and the interrupted 
bus master generates its own restart 


address to service that interrupt. 
The Multibus 
address 


or data 
lines are not 
used. A 
BVI 
uses the 
Multibus 


address and data lines to communicate 
with 
the inter- 


rupting 
slave. When the slave module generates an inter- 


rupt, the bus master requires that module to generate the 
restart 
address. 
One 
additional 
command 
signal 
is 


4. Open loop. Shown above is a simple alarm and monitoring system. The iSSG 711 analog-input board samples 16 differential inputs and the 


8-bit iSSG 80/20 
compares the inputs to the high and low limits. An alarm condition illuminates an LED and gets logged·on a teletypewriter. 


5. Cloaed loop. Suppose the system in Fig. 4 needs to be upgraded to handle a closed-loop 
system. For this application 
an iSSG 86/12 
replaces the 80/20-04 
to cope with the higher processing. The output control variables are handled by an iSSG 724 analog-output 
board. 


8. Multi/maater. 
To enhance the control system in Fig. 5, add a dedicated GPU to control valves, vents, and dampers that, in turn, affect 
pressure and flow parameters in the system. This has been done by adding an iSSG 80/05 
in a Multibus/multimaster 
arrangement. 


defined-interrupt 
acknowledge (INTA)-to 
request the 


restart address from the slave module. 
The iSBC 86/12 board architecture, 
like that of the 


8-bit iSBC 80130, is organized around a three-bus hier- 
archy: an on-board bus, a dual-port bus and a system bus 
(Multibus). 
All three buses have been expanded over 


their 80/30 counterparts 
to incorporate 20 address lines 


and 16 data lines. 


The iSBC 86/12 architecture 


The on-board bus links the 8086, all the 
110 peripher- 


als, and the read-only memory. Next in the hierarchy is 
the dual-port bus, which connects to the DP controller, 32 
kilobytes 
of dynamic 
RAM, and 
the 
dynamic 
RAM 


controller. Finally, the system bus permits expansion of 
system resources through Multibus modules (Fig. 2). 


The bus protocol of the iSBC 86/12 dictates that each 


of the three buses communicate with an adjacent bus or 
operate independently. 
When the CPU makes a request 


for a resource, the on-board and dual-port buses simulta- 
neously determine 
if their 
hardware 
can 
fulfill the 


request. If the on-board bus is able to acknowledge the 
request, it does so and the DP bus is not disturbed. (The 


DP bus is not interrupted 
to determine 
whether it can 


acknowledge the request.) The 8086 always controls the 
on-board 
bus, 
and 
requested 
operations 
can 
be 


completed without delay. If the DP bus is needed, it is 
requested and the dual-port controller grants the use of 
the bus to the processor. Thereafter, 
the dynamiC-RAM 


controller 
completes 
the operation 
and 
generates 
an 


acknowledge. 
If neither the on-board nor the DP bus can satisfy the 


request, the CPU asks for the system bus. The 8086 must 
use the on-board and dual-port 
buses to communicate 
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7. Four loop•. An iSSG 86/12 
can be used in conjunction 
with an iSSG 544 intelligent communications 
controller to perform a supervisory 
function for four closed-loop systems. The iSSG 544 controls the line protocol and the iSSG 86/12 
processes the 544's data. 


with the system bus. The 8086 takes control of the 
OP 
bus when the system bus is granted. This prevents lock- 
out problems with the OP bus-that 
is, when the proces- 


sor requests the system bus while another bus master has 
control of it and is accessing the dual-port 
RAM. 
Naturally, 
the fewer the buses it has to access, the 


faster 
the iSBC 86/12 
completes 
a transaction. 
The 


on-board bus always operates at maximum board speed. 
But the OP bus operates at maximum board speed only if 
it was not busy or taken up with a memory refresh cycle. 
When the system bus is brought into play, the processor 
speed depends on the overhead in acquiring it and the 
type of Multibus module being accessed. 
With this three-bus architecture 
the iSBC 86/12 can 
be operating over its on-board bus at the same time as 
another Multibus master is using the system bus. It does 
so by accessing data from the OP RAM at no reduction in 
board speed. The on-board bus permits access only from 
the 8086. Thus all 110 and ROM are private to the 8086. 
The dual-port controller has two independent address 
decoders-one 
for the 8086 and one for the Multibus. 
The 8086 decoder fixes the 8086's 
RAM addresses from 


hexidecimal 
00000 
to 
07FFF 
using 
a 
fusible-link 


programmable 
ROM. The Multibus decoder allows the 


user to select any address range for the on-board RAM by 
specifying 
two parameters-a 
top-of-memory 
pointer 


and the size of the accessible memory. The TOM pointer 
(as seen by another Multibus master) can be set to any 
8-kilobyte boundary in the I-megabyte 
memory space. 


The amount of memory on the iSBC 86/12 accessible by 
another master can be set to 8,16,24, 
or 32 kilobytes (or 


no access) with an on-board jumper. For example, fixing 
the accessible memory size to 24 kilobytes provides the 
8086 with 8 kilobytes of RAM that only it can access. 
This private area can be used for the processor's stack, 
interrupt jump table and other special system paramet- 
ers that 
are generally 
protected 
from other 
Multibus 


masters. 
The only addressing 
restriction 
is that 
the 


memory block accessible to the Multibus cannot cross a 
128-kilobyte boundary. 
. 


Suppose a Multibus master wants to load a program 


into the iSBC 86/12's 
dual-port 
RAM 
for execution. 


Since the 8086's view of the 
OP-RAM 
address space is 
fixed, the Multibus address must be translated 
into the 
on-board 
8086 
memory 
space. 
The 
OP 
controller 


performs this translation 
by mapping the TOM pointer 
(as seen by other 
Multibus 
masters) 
to 8086-address 


07FFFH, 
the top of the 8086's on-board 
RAM. 
Point- 
er - I is mapped to the top of 8086 on-board 
RAM - I, 


and so on. 


In the example shown in Fig. 3, the Multibus address 


selection is divided into three parts- 
two selecting the 
TOM pointer (X and Y) and one selecting the size of the 
accessible memory (Z). The TOM pointer is equal to a 
I28-kilobyte segment (X) plus address displacement (Y) 
from that segment. In this example, X is set to COOOOH 
and Y is set to OBFFFH, so the 
TOM pointer equals 


CBFFFH. Next, the size of the accessible memory (Z) is 
set, in this case to 8 kilobytes. This address translation 
makes the top 8 kilobytes of the 8086's 
RAM locations 


06000H 
to 07FFFH 
available 
to another 
Multibus 


master 
when 
it 
addresses 
locations 
CAOOOH to 


CBFFFH. 
The 8086 still has 24 kilobytes (OOOOOHto 


05FFFH) of private memory. 


Multiprocessing 
schemes 


In multiprocessing systems, a master must be able to 


access the system without another master obtaining the 
bus. The iSBC 86/12 incorporates bus-arbitration 
logic 


to effect these transactions. Since the system bus is only 
requested when a system resource is needed, the iSBC 
86/12 can perform true parallel processing with other 
iSBC 80 or 86 masters. 


A typical example is the use of a common memory 


location that contains the status byte (busy/not 
busy) of 


a floppy-disk controller. When the floppy disk is needed, 
the master must first read the location and, if not busy, 
write the status word without another master obtaining 
the bus (to use the floppy disk). A bus-lock function on 
the iSBC 86, once enabled, 
allows the 
iSBC 
86 to 


maintain 
control of the system bus until the lock is 


disabled by program control. This bus-lock function may 


NEW MULTIBUS 
MEMORY ORGANIZATION 


Data 
Master 
BHEN 
ADRO 
Data paths 


LOW EVEN 
BYTES 
EVEN-BYTE 
BUFFER 
00-7 


B-bit 
B-bit 


even 
16-bit 
0 
0 
SWAP-BYTE 
BUFFER 


address 
mixed 


HIGH 
ODD BYTES 
ODD-BYTE 
BUFFER 
DB-F 


LOW EVEN 
BYTES 
EVEN-BYTE 
BUFFER 
00-7 


'6-bit 
'6-bit 
0 
SWAP-BYTE 
BUFFER 


HIGH 
ODD BYTES 
ODD-BYTE 
BUFFER 
DS-F 


LOW EVEN 
BYTES 
EVEN-BYTE 
BUFFER 
00-7 


B-bit 
B-bit 


odd 
'6-bit 
0 
SWAP-SYTE 
BUFFER 


address 
mixed 


HIGH 
ODD BYTES 
ODD-BYTE 
BUFFER 
DS-F 


be activated in one of two ways- by an output bit from 
the resident 
8255A peripheral-interface 
chip or by a 
software prefix on any 8086 instruction. 
The iSBC 86 


can perform the test and set function by exchanging the 
accumulator 
with the memory location, preceding the 


instruction 
by a lock prefix. For example, 
the status 


word is read into the accumulator 
and, without another 


intervening 
bus cycle, a busy status 
is written. 
The 


accumulator is then tested: if busy-try 
again (writing a 


busy does not destroy status as it was already busy); if 
not busy, the floppy disk is now under the master's 
control and the status location is set to busy. 


The iSBC 86/12: 
a design tool 


For system debugging and full-speed execution, the 


iSBC 86/12 can be linked to the Intellec microcomputer 
development system. Programs generated on the Intellec 
system can be downloaded into the iSBC 86/12 
RAM via 


cables. Through a virtual-terminal 
capability, the Intel- 


lec console can directly access an iSBC-resident monitor, 
which provides commands for software debug. Once the 
debugging cycle is completed, the user has the option of 
uploading the software back to the Intellec for storage 
on diskettes. 
The Multibus 
and form-factor 
compatibility 
of the 


8-bit iSBC 80 and 16-bit iSBC 86 single-board comput- 
ers provide a degree of design flexibility previously unob- 
tainable. 
Initial 
design problems 
can be solved with 


low-cost 
8-bit 
hardware. 
As 
product 
requirements 
evolve, 16-bit performance can be added. Eventually, 8- 
and 16-bit multiprocessor solutions can be conveniently 
implemented. 
Consider the application 
shown in Fig. 4, an alarm 


and monitoring system in a typical process plant. Sixteen 
differential 
inputs from pressure and flow transducers 
are sampled once every second, then compared to high 
and low limits previously entered through thumbwheel 


switches. The iSBC 711 analog-input board takes care of 
sampling the inputs and the 8-bit iSBC 80120-4 com- 
pares Jhe data to the high and low limits. Whenever 
these lImits are exceeded, an alarm LED lights up and the 
alarm condition is logged on the system teletypewriter 
along with input identification, high limit, low limit and 
sampled value. 


Closed 
loops 


Instead of an open-loop system, suppose the design 


must be enhanced 
to control four output 
variables- 


thereby making it a closed-loop system. The sampling 
rate must be increased to once every third of a second 
and more processing will be required to run through the 
control algorithm and output the control-loop data. For 
this application, and iSBC 86/12 replaces the 80120-4 to 
handle the higher processing requirements. An iSBC 724 
analog-output 
board is also added to provide the four 


output-control 
variables 
(see 
Fig. 
5). 
Carrying 
this 


example one step further, 
one may want to dedicate 
another processor to controlling valves, vents, and damp- 
ers that in turn affect pressure and flow parameters 
in 


the system. This can be done by adding an iSBC 80/05 
in a multimaster arrangement as shown in Fig. 6. 


Finally, an iSBC 86/12 can be used with an iSBC 544 
intelligent 
communication-controller 
to supervise 
four 
closed-loop systems of the type shown in Fig. 6. The 
86/12 
of each system interfaces 
with the supervisory 
system via its serial interfaces, which are connected to 
the iSBC 544's serial ports (see Fig. 7). The iSBC 544 
performs the control functions associated with the line 
protocol. The supervisory iSBC 86/12 
can access the 


iSBC 544's dual-port memory and can perform further 
processing of the data received from the four closed-loop 
systems. In this configuration large amounts of memory 
may be required; since the iSBC 86/12 can address up to 
I megabyte, this presents no problem. 
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A new family of MULTIMODULETM boards 


extends the solutions provided by 


Intel's single board computers 


Figure 1. The iSBX 350™ 
Programmable 
110 MULTIMODULEplug-in, 


shown here, connects directly on one end into the special iSBX 
bus connector and screws onto the edge 01 the single board com· 
puter on the other end. 


A 


complete 
new 
family 
of products, 
called 


MULTIMODULE 
boards, has been announced 


by Intel 
Corporation 
The 
new 
MULTI- 


. 
MODULE boards designed to extend the func- 


tional 
capabilities 
of single board computers 
at much 


lower cost than has been previously 
possible. 
Intel is 


supporting 
the MULTIMODULE 
concept 
with 
a new 


bus standard-the 
iSBX bus. The iSBX bus will now be 


designt;d into a new generation 
of single board com- 


puters to achieve compatibliity 
with the emerging iSBX 


bus compatible 
MULTIMODULE 
product line. Users of 


Intel's 
single 
board 
computers 
can 
increl11en tall y 
expand system resources by addin~ small 
1285" 
x 37"} 


iSBX MULTIMODULE 
boards' which plug directly into 


iSBC boards.' 


Three new iSBX bus MULTIMODULE 
plug-ins have 


been introduced-modules 
for parallel I/O, 
serial I/O, 


Figure 2. The iSBX 350™ Programmable 
liO MULTIMODULETM 


board provides 
24 programmable 
110 lines using the 8255A·5 pro- 
grammable 
peripheral 
interface. 
Sockets 
are provided 
for inter· 
changeable 
line drivers/terminators. 


Figure 3. The iSBX 351™ Serial I/O MULTIMODULE 
board extends 


the serial communications 
capability 
of a single board c\lmputer 


via an Intel~ 8251A USART. It includes 
an on·board 
programmable 
baud rate generator, 
two programmable 
16·bit BCD/binary 
timers, 


and RS232C or RS422/449 interfacing. 


Figure 4. The iSBX 332™ Floating 
Point Math MULTIMODULE 


board uses an Inte" 
8232 Floating 
Point Processor 
and is com· 


patible 
with the new proposed 
IEEE format. 
It provides 
users with 


both single·precision 
(32·bil) and double·precision 
(64·bit) 


arithmetic 
functions. 


and floating-point 
math. The showcase for the MULTI- 


MODULE 
family is the iSBC 80/10B 
board-the 
first 


iSBX bus compatible 
single board computer. 


MULTIMODULETM boards allow users to 


tailor board level products 


Customers 
can choose 
MULTIMODULE 
boards 
to 


precisely configure single board computers 
for their in- 


dividual applications 
at a lower cost. The MULTIMOD- 


ULE boards enable users to buy exactly the capabilities 
that 
they require 
for their 
iSBC-based 
systems. 
This 


can, of course, 
keep system 
size and system 
cost at a 


minimum. 


Any of the three 
new 
iSBX bus MULTIMODULE 


products-the 
iSBX 350 Programmable 
I/O, 
the iSBX 
351 Serial 1/0, 
and the iSBX 332 Floating Point Math 


board-plug 
into a special interface called the iSBX bus 
on the iSBC 80 I lOB single board computer, 
(see Figure 


I). The iSBX bus is being introduced 
by Intel to facilitate 


the 
interface 
betweeen 
the 
iSBX MULTIMODULE 
boards 
and 
the 
iSBC products. 
The 
iSBX bus 
will 


become a standard, 
similar to the standard 
MULTIBUS 
system architecture. 
The new iSBX bus allows system 


expansion 
through 
the new 
MULTIMODULE 
boards 


without 
making any demands 
on the system's 
MULTI- 


BUS interface. 
As a result, 
the system 
design achieves 


maximum 
on-board 
performance 
while freeing up the 


MULTIBUS interface for other system 
activities. 


The new iSBC 80110B single board computer 
is fully 


compatible 
with 
the popular 
iSBC 80110A, 
but it is 


customer-expandable 
in "all directions~' This board ean 


be expanded 
in three 
dimensions 
to tailor 
EPROM, 


RAM, and I/O needs directly on the board. This gives a 
user a built-in 
adaptablility 
on one board 
that 
was 


previously 
unattainable. 
First, the user can choose four 


types of Intel PROMs-the 
2708, 2758, 2716 or 2732- 
expandable 
up to 16K bytes. 
Second, 
IK of RAM 


memory 
is included on-board and may now be extended 


up to 4K with the use of, standard 
Intel 2114A-5 IK x 4 


static RAMs. Sockets on the 80/10B 
board are provided 


for these additional 
RAMs. Input loutput 
is the third 


dimension 
in every single board computer 
and may now 


be expanded on-board the iSBC 8011GB by using one of 
the iSBX bus MULTIMODULE 
boards. 
In addition, 
a 


1.04 millisecond 
timer 
has been added as a standard 


feature of the iSBC 80/]OB 
board. In comparison, 
the 


iSBC 80 I lOA board has onl y IK of on -board RAM, 8K of 
EPROM 
memory, 
no I I 0 
or memory 
expansion 


facilities and no timer. 


Two of the new MULTIMODULE 
boards-the 
iSBX 
350 and iSBX 351-provide 
expansion 
to the 
1/0 


already on the iSBC 8o/]oB 
board. The iSBX 350 Pro- 


grammable 
I/O 
MULTIMODULE 
(see Figure 2) pro- 
vides 24 I/O lines with sockets for interchangeable 
line 


Here's what iSB)(TMbus MULTIMODULES™ 
provide the user: 


• The ability 
to incrementally 
expand 
the iSBC Single 
Board Computer, 
via iSBX bus, allowing 
the user to 


add only the function 
his application 
requires. 


• The on·board 
addition 
of totally 
new capabilities 


(mathematics 
processing 
and the like) to single 
board computers. 


• Maximum 
performance 
by reducing 
traffic 
required 


for standard 
expansion 
boards on the industry 
stan- 


dard MULTI BUS interface. 


• Compatibility 
with future B-bit and 16-bit single 
board computers 
from Intel 


• A high-reliability. 
36-pin iSBX 960-5 male connector 
for customer 
design 


drivers 
and terminators. 
The 
iSBX 351 Serial 
I/O 
MULTIMODULE 
(see Figure 
3) provides 
program- 
mable, 
synchronous 
/ asynchronous 
RS232C 
or 
RS422 /449 compatible 
serial expansion 
with fully soft- 


ware selectable 
baud rate generation. 
Additionally, 
two 


programmable 
16-bit 
BCD and 
binary 
timers 
are 
available, 
allowing 
iSBC 801l0B 
users to implement 
programmable 
timing functions 
directly on the board. 


A third 
MULTIMODULE 
board which 
users 
may 


select, 
provides 
additional 
on-board 
mathematics 
capability 
to their single board computer. 
The iSBX 332 
Floating Point Math MULTIMODULE 
board (see Figure 


New iSBX 960-S™ 
MULTiMODULE™ 
connectors 
are available 
off· the-shelf 


4) is compatible 
with 
the proposed 
IEEE format 
stan- 
dard. 
It offers 
single-precision 
(32-bit) 
and double- 
precision 
(64-bit) arithmetic 
functions 
including 
Add, 


Subtract, 
Multiply 
and Divide. It also includes 
end-of- 


operation 
and error interrupts 
to its host iSBC single 


board computer 
and full software reset control. 


User may easily implement 
their more specialized 


requirements 
on the new iSBX bus through 
a readily 
available 
36-pin 
male 
connector, 
the 
iSBX 960-5 


(packaged with 5 connectors). 
In addition, 
Intel is pro- 
viding 
an iSBX bus specification 
describing 
the elec- 


trical and mechanical 
parameters 
of the interface. 
The 


iSBX 960-5 male connectors 
mate directly to the female 


iSBX bus connector 
on the iSBC 801l0B 
single board 
computer. 
The connector, 
together 
with the iSBX bus 


speCification, 
allows system 
designers 
to take full ad- 


vantage of MULTIMODULE 
benefits. 


New MULTIMODULES 
boards will be introduced- 
as will new generation 
iSBX bus compatible 
iSBC single 


board computers-by 
Intel throughout 
the remainder 
of 


1980 and into the future. 
MULTIMODULE 
boards and 


the iSBX bus represent a maior commitment 
by Intel for 
the future 
and offer system 
designers 
new options 
to 
complement 
single board computers 
and MULTIBUS 
expansion. 


The 
immediately 
available 
MULTIMODULE 
family-with 
the iSBC 80/lOB single board computer- 


provides great flexibility 
and savings for users. The op- 
tions now exist to expand a system in small increments 
with MULT1MODULE 
boards, or in large increments 


with MULTIBUS boards. 
And, with the three dimen- 


sional expansion 
capability 
of the iSBC 80/ lOB board, 
the user may configure 
his entire 
system 
on-board 
to 
achieve a single board, low cost solution. 


PRJCE: 
Call your local Intel sales office or distributor 
for 


the latest prices on all of the MULTIMODULE 
products 


AVAJLABILlTY: 
Now 
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Special-function modules 
ride on computer board 


Smaller cards donate floating-point 
processing or added serial and parallel I/O 


to primary single-board 
computer; 
memory is extensible on the main card 


o 
In the 
design 
of 
board-level 
computers, 
two 
basic 
methods 
coexist. 
One 
is to pack 
each 
card 
with 
inte- 


grated 
circuits 
to the limits 
of its capacity, 
and the other 


is to 
distribute 
the 
computer 
functions 
among 
other 


boards 
occupying 
additional 
card slots. 
Both 
approaches 
have 
their 
advantages. 
The 
single 
powerful 
module 
conserves 
space 
and expensive 
connec- 


tors, 
while 
the 
decentralized 
boards 
allow 
the 
user 
to 
pick and 
choose 
functions-and 
add 
them 
incremental- 
ly-although 
the expense 
of one board 
might 
spell over- 


kill for one particular 
application. 
A new concept 
in single-board 
computer 
architecture 
strikes 
a neat 
compromise 
between 
both 
camps. 
Rather 


than 
cram 
more 
chips 
on an already 
overstuffed 
board, 
the 
idea 
is simply 
to 
provide 
it with 
a connector 
for 


plugging 
in smaller 
modules 
having 
limited 
functions 
for 


specialized 
applications. 


Best of both worlds 


This 
is the 
idea 
behind 
iSBX 
Multimodule 
boards, 
which 
cost 
from 
$155 
to $450 
apiece. 
Plugging 
into 
a 


primary 
processor 
card, 
10.5-square-inch 
boards 
with 


various 
types 
of memory 
or input 
and 
output 
functions 
provide 
the larger 
single-board 
computer 
with more ver- 


satility. 
Linking 
the base 
board 
and 
these 
Multimodule 
boards 
is a new 
36-line 
bus 
called 
the 
iSBX 
bus, 
for 


single-board 
expansion. 
This 
interface 
is destined 
to 
match 
the popularity 
of the main board's 
Multibus 
inter- 
face connector 
(Fig. 
I). 


The 
iSBX 
bus 
is derived 
directly 
from 
the 
on-board 


microprocessor 
system 
bus 
and, 
as 
such, 
an 
iSBX- 


compatible 
board 
becomes 
an 
integral 
element 
of the 
single-board 
computer. 
The 
physical 
interface 
uses 
a 


unique 
connector 
designed 
specifically 
for the iSBX 
bus. 
The 
bus is brought 
to a female 
connector 
on the single- 


board 
computer; 
its male 
equivalent 
is resident 
on the 
iSBX board 
(Fig. 2). 


The 
iSBC 
80/ IOB board 
in Figs. 
I and 
2 is the 
first 


single-board 
computer 
to be compatible 
with 
the 
iSBX 


bus. Upwardly 
compatible 
with its predecessor, 
the iSBC 
80/l0A, 
the iSBC 
80/IOB 
is functionally 
equivalent 
but 
offers significant 
enhancements. 


The 
iSBC 
80/l0B 
board 
offers 
direct 
functional 


expansion 
in three 
dimensions-not 
only read-only 
mem- 


ory 
(as 
in the 
iSBC 
80/IOA), 
but 
also 
static 
random- 


access 
memory 
and 
input 
and 
output, 
as facilitated 
by 
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the 
Multimodule 
boards. 
One 
kilobyte 
of static 
RAM is 


provided 
along 
with sockets 
for expansion 
in increments 


of l-K bytes to 4-K bytes using standard 
2l14A-5 
memo- 


ries. Read-only 
memory 
may be expanded 
with standard 


ultraviolet-light-erasable 
and mask-programmable 
types 


to 16- K bytes. 


The 
iSBC 
80/IOB 
also 
features 
an 
on-board 


1.04-millisecond 
timer 
with 
ongoing 
clocking 
that 
users 


may 
optionally 
configure 
for microprocessor 
interrupts. 
In addition, 
power-fail 
control 
is provided 
for the 2114A- 


5 static 
RAMs, enabling 
the user to add battery 
backup 
if 


the memory 
contents 
must be preserved. 


Three 
Multimodule 
boards 


Being 
introduced 
along 
with 
the 
iSBC 
80/IOB 
are 


three 
Multimodule 
boards 
that 
expand 
the 
functional 
capacity 
of the single-board 
computer. 
Two of these, 
the 
$155 
iSBX 
350 and 
$230 
iSBX 
351, 
provide 
the 
same 


kind of input/output 
functions 
as are to be found 
on the 


processor 
board, 
only more of them. 
For example, 
the 
48 programmable 
1/0 lines 
on the 


iSBC 
80/ IOB board 
may 
be expanded 
to 72 lines 
by 
simply 
plugging 
in 
the 
iSBX 
350 
module-a 
50% 


increase. 
Serial 
1/0 is similarly 
expanded 
with the iSBX 


351 
module, 
which 
provides 
a programmable 
universal 


synchronous-asynchronous 
receiver/transmitter, 
or 
Usart 
(an 8251 A), for compatibility 
with the 
RS-232-C 
and 
RS-449/422 
interfaces. 
The 
iSBX 
351 module 
fur- 


ther 
offers 
software-selectable 
baud 
rates 
and 
two pro- 


grammable 
16-bit 
binary 
or 
binary-coded 
decimal 


timers. 


The third 
Multimodule 
board 
adds otherwise 
unavail- 
able 
high-speed 
math 
capabilities 
to the 
iSBC 
80/ IOB 


board. 
The $450 iSBX 
332 board 
uses the 8232 floating- 


point 
processor 
for arithmetic 
compatible 
with the stan- 
dard 
currently 
being proposed 
by the Institute 
of Electri- 
cal and Electronics 
Engineers. 


Many 
applications 
require 
a custom 
design. 
To com- 
plement 
the standard 
family 
of Multimodule 
boards, 
the 


iSBX 
960-5 
is provided. 
This 
includes 
five male 
iSBX 


connectors, 
and 
a full bus specification 
is available 
for 


custom 
interfacing 
by the 
user. 
This 
combination 
per- 
mits a user to satisfy 
his or her requirements 
for special- 


ized I/O interfaces 
with the Multimodule 
concept. 


The 
Multimodule 
concept 
can 
be 
divided 
into 
two 


logical 
clements: 
base 
boards 
and 
Multimodule 
boards. 


RS 232·C 
COMPATIBLE 


DEVICE 


SCRIAL 
DATA 
CONTROL 
INTERFACF 


SERIAL 
DATA 
CONTROL 
INTERFACE 


BAUD·RATE 
SELECTOR 
(JUMP€ RS) 


L. 


JUMPER 
~ 
§ 


SELECTED 


SOCKETS 
FOR 


16 K-BY-B 
BIT 


REAO·ONLY 
MEMORY 
DR ERASABLE 
PROGRAMMABLE 
ROM 


IK-6Y-B 
BIT 
RANDOM 
ACCESS 
MEMORY 
(SDCKFTS 
TO 
4 K BY B BITS) 


PROGRAMMABLE 
COMMUNI 
CATIONS 


INTERFACE 
(USARTI 


USER·DESIGNATED 
,SBX MUL T1MODULE 
BOARD 


4B PROGRAMMABLE 
PARALLEL 
INPUT 
OUTPUT 
LINES 


L04rns 


INTERVAL 


TIMER 


DRIVER! 


TERMINATOR 


INTERFACE 


,SBX BUS 
MULTIMODULE 
CONN ECTO R 


80BOA 


CENTRAL 
PROCESSING 
UNIT 


PROGRAMMABLE 
PERIPHERAL 
INTERFACES 


1. Distributed. 
The flrsl processor 
cerd 
10 receive 
the iSBX bus connector 
is the iSBC 801 lOB, a follow-on 
~o the iSBC 801 lOA. 
The off-board 


system 
bus is the Multibus, 
which 
interfaces 
to the on-bomd 
system 
bus. This, in turn, connects 
to the Multimodule 
board 
connector. 


The 
base 
board 
is the 
Illaster 
of the 
system 
in that 
it 


controls 
cOlllmunication 
betwecn 
thc basc's 
microproces- 


sor and 
the 
Multimodule 
board's 
port. 
Though 
the 
first 


base 
board 
is 
a 
single-board 
computer 
the 
iSBC 


!lO/IOB 
Multibus-compatible 
slavcs and 
intelligent 
1/0 


boards 
will 
also 
incorporate 
iSBX 
bus 
interraces. 
Thc 
Multimodule 
board 
is a slavc 
of the 
system 
in that 
it 


carrics 
out I/O comlllands 
rrom the basc board. 


The iSBX interface 


The 
iSBX 
bus 
specification 
includes 
both 
electrical 


and 
meehanical 
charactcristics. 
The 
Illechanical 
inter- 


race is eonvenient 
and rugged: 
the Multimodule 
board 
is 


mounted 
to the base board 
in two placcs. 
at the top with 


a screw 
and 
at the 
bottom 
by the 
iSBX 
bus conncetor. 


The 
connector 
is extremely 
reliable. 
It has gold-plated 


phosphor-bronlc 
contacts, 
it is keyed 
to assure 
proper 


orientation, 
and 
a shroud 
protects 
its pins 
during 
han- 


dling. 
Thc 
conncctor 
also 
incorporates 
interlocking 
tabs 
to ensurc 
a solid mechanical 
interrace. 


Electrically. 
the 
iSBX 
bus 
interrace 
lines 
can 
be 
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grouped 
into 
six 
classcs 
- control. 
address 
and 
chip 
select. 
data, 
interrupts, 
options, 
and 
powcr 
for a total 


or 36 signallincs. 
Control 
lincs 
can 
be 
further 
grouped 
into 
thosc 
ror 
comlllands. 
initialilation, 
a clock. 
and 
systcm 
control. 


The 
two 
cOlllmand 
lines 
(IOR!)/ 
and 
IOWRT/) 
arc 


active-low 
I/O-read 
and 
-writc 
signals 
that 
control 
the 
communication 
link 
between 
the 
base 
board 
and 
the 


Multimodule 
board. 
With 
a chip-select 
signal. 
an active 


command 
linc indicates 
that 
the address 
lincs arc 
valid 


and that 
the Multimodulc 
board 
should 
pcrform 
a speci- 


ficd operation. 


Thc 
initialize 
line (reset) 
is an active-high 
input 
line 


rrom 
the 
base 
board 
that 
puts 
the 
Multimodule 
board 


into a known 
intcrnal 
state. 
The clock 
line (MCI.K) has a 


rrequency 
or 10 megahertz, 
+O'J, 
or -IO'J,. 
Being asyn- 


chronous 
with 
rcspect 
to all other 
MultimoduJc 
signals, 


this rrequency 
can vary rrom base board 
to base board. 


The 
remaining 
control 
lincs, 
MWAIT/ and 
MI'ST, are 
output 
signals 
rrom 
the 
Multimodule 
board 
that 
control 


the 
state 
or the 
systcm. 
MWAIT/. 
active 
low. 
puts 
thc 


2. Three 10 one. Below is the iSBC 801 10B main processor board, and above it are the three new Multimodule boards. They are, from lell to 
right, the iSBX 351 serial 110 module, the LSBX 350 parallel 110 module, and the iSBX 332 floating-point 
mathematics Multimodule board. 


base-board 
processor 
into 
a 
wait 
state, 
allowing 
the 
Multimodule 
board 
extra 
time 
to perform 
a requested 


operation, 
if 
necessary. 
MWAITI 
is 
generated 
from 


address 
and chip-select 
information 
only. 
MPST is tied to 


ground 
on the 
Multimodule 
board 
to inform 
the 
base 
board 
that a Multimodule 
board 
has been installed. 


The 
second 
class 
of 
iSBX 
bus 
lines 
includes 
the 


address 
lines 
(MAo-MA,) 
and 
the 
chip-select 
lines 
(MCSol 
and 
MCSII). 
The 
base 
board 
decodes 
1/0 


addresses 
to 
generate 
the 
chip-select 
signals 
for 
the 
Multimodule 
boards. 
In so doing, 
it normally 
decodes 
all 


but 
the 
three 
lowest-order 
addresses 
(MAo-MA,). 
A 
base 
board 
normally 
reserves 
two 
blocks 
of eight 
I/O 


ports 
for each 
iSBX bus connector 
provided. 


Defining 
the lines 


Eight 
bidirectional 
data 
lines 
(M Oo-M 07, 
active 
high) 
carry 
information 
to and 
from 
the 
Multimodule 
ports. 
MOo 
is the 
least 
significant 
bit. 
The 
two 
active 


high 
interrupt 
lines 
from 
the 
Multimodule 
'board, 


MINTRo 
and 
MINTR" 
make 
interrupt 
requests 
to the 


base board. 


Two optional 
lines, OPTo and OPT\, 
are connected 
to 


wire-wrapped 
posts 
on both 
the 
base 
and 
Multimodule 


boards. 
They 
may 
serve 
either 
as additional 
interrupts 
from 
the 
Multimodule 
board 
or as special 
signals 
from 


the base board. 


Electronics 
/ April 
10, 1980 


Finally, 
all base boards 
provide 
+ 5 and ± 12 volts to 


the Multimodule 
boards. 
These 
power 
lines complete 
the 


six iSBX bus classes. 
The 
primary 
function 
of the iSBX 
bus is to provide 
a 


path 
for I/O-mapped 
data 
between 
base board 
and 
Mul- 
timodule 
board. 
This 
happens 
when 
the base 
board 
per- 


forms 
an I/O-read 
or I/O-write 
operation. 
There 
are two 


types 
of 
I/o-write 
operations, 
and 
the 
Multimodule 


board 
determines 
which 
is performed. 


Data transfers 


'The 
first 
is a full-speed 
I/O write 
(Fig. 
3). The 
base 


board 
generates 
a valid 
1/0 address 
and 
chip-select 
and 
activates 
the JOWRTI line after 
the set-up 
times 
are met. 


The 
IOWRTI line will remain 
active 
for a minimum 
of 


300 nanoseconds 
and 
the data 
will be valid 
for a mini- 


mum 
of 
250 
ns before 
IOWRTI 
is removed. 
The 
base 


board 
then 
removes 
the 
data, 
address, 
and 
chip-select 


signals 
after 
the hold times shown 
in the timing 
diagram. 


The 
alternative 
1/0 
write 
is· a 
write-with-wait, 


used 
by Multimodule 
boards 
that 
cannot 
write 
into 
an 
I/O port at full speed. 
Again"the 
base board 
generates 
a 


valid 
address 
and 
chip-select. 
The 
Multimodule 
board 


activates 
the 
MWAIT/ signal 
based 
on address 
and 
chip- 


select 
information. 
This 
will remove 
the ready 
condition 
from the processor, 
causing 
it to go into a wait state 
after 
the 
write 
command 
has 
been 
activated 
and 
valid 
data 


ADDRESS 
IMAo-MA,1 


CHIP SELECT 
IMCS,) 


3. Write types. Two modes of sending information to a Multimodule board are available: full-speed and with a wait state. The wait line is not 


used for peripherals that meet the full-speed specifications. The wait signal extends the time for which data remains valid. 


provided. 
The 
Multimodule 
board 
will 
remove 
the 


MWAITI 
signal-allowing 
the processor to leave its wait 


state-when 
it 
has 
satisfied 
the 
write-pulse-width 
requirement. 
The base board removes the write com- 


mand, then the data, address, and chip-select signals, 
after the hold times are met. 


There are two types of I/o-read operations as well, and 


again they are determined 
by the Multimodule 
board. 
The first is a full-speed 
liD 
read (Fig. 4). The base 
boa'rd generates a valid 110 address and chip-select and, 
after the set-up timings are met, it activates the 10RDI 
line. The Multimodule 
board must generate valid data 
from the addressed 
1/0 port in less than 250 ns. The base 
board 
reads 
the 
data 
and 
removes 
the 
command, 


address, and chip-select signals as indicated in the timing 
diagram. 
Read-with-wait, 
whose timing is at right in Fig. 4, is 
used by Multimodule boards that cannot perform a read 
operation 
under the full-speed specifications. The base 


board generates a valid address and chip-select, just as 
with a full-speed read. However, the Multimodule board 
now activates the MWAITI 
signal, which in turn removes 
the ready input to the base's processor, putting it into a 
wait state. 
The processor 
activates 
the 
10RDI 
signal 
before going into a wait state. 
The Multimodule 
board will remove the MWAITI 
sig- 


nal when valid data can be read from the data bus. After 
reading the data, the base board removes the command, 
address, and chip-select signals. 
The iSBX 351 serial 
110 board is a good example of 
how easily large-scale integrated 
circuits may be inter- 


faced by the iSBX bus. It presents the iSBC 80/IOB 


ADDRESS 
IMAo-MA,) 


CHIP SELECT 
(MCS,l 


board with a second serial port. 


The iSBC 351 board (Fig. 5) provides a synchronous 


or asynchronous 
serial communications 
channel 
with 


programmable 
format and baud rates up to 64 kilobits 


per second. In the synchronous mode, the user selects via 
software the number and format of the synchronization 
characters 
and the number of data bits. Parity may be 
even, odd, or disabled. 
In the asynchronous 
mode, the 


number of data 
bits and stop bits, as well as parity 


generation 
and detection, 
may be specified under pro- 
gram control. 
The added channel 
is compatible 
with 


either the RS-232-C or RS-422/449 
interface. 


Two additional 
16-bit counters are on the board for 


other uses. Their mode of operation and count value may 
be written or read under program 
control. 
With the 


interrupt lines provided by the iSBX bus, they may also 
be used as real-time interrupt sources (see Table I). 


As stated earlier, an 8251A Usart gives the iSBX 351 


module a high-performance 
communications channel. In 


addition, 
an 8253 programmable 
interval 
timer 
(PIT) 


provides the three counters 
for clock generation 
and 


timing. Note in the block diagram 
of Fig. 5 that both 


devices are connected directly to the data, address, and 
command buses with no buffers. (Each chip, however, 
has its own chip-select line, preventing data bus conten- 
tion.) The absence of buffers keeps the parts count down 
and the speed up. 


Also shown in the extra block diagram are two option- 


al lines that may be used as additional interrupt 
lines or 


to interface to the additional timer/counters. 
There are 


four interrupt 
sources on the board. 
Two, from the 


8251A, indicate either that a character has been received 


4. Read types. 
As in writing data into a Multimodule board, information is read from it in one of two ways: full speep or read-with-wait. 
The wait 
state extends the length of time that data is valid. This is necessary for slower transactions such as analog-to-digital 
conversions. 
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5. More serial I/O. 
The iSBX 351 serial input / output Multimodule board provides the base processor with an additional synchronous or 
asynchronous communications channel-one 
that is compatible with either the RS-232-C or the RS-422/449 interface specifications. 


for reading 
or that 
the 
transmitter 
buffer 
is empty 
and 


ready 
for 
transmission. 
Two 
other 
interrupts 
may 
be 
generated 
by the timer/counters. 
The 
timers 
count 
from 


an on-board 
crystal-controlled 
oscillator. 


Compatible 
with both 


The 
iSBX 
351 
module 
uses 
a unique 
split-edge 
con- 
nector 
to provide 
compatibility 
with both 
RS-232-C 
and 
RS-449 
interfaces. 
RS-232-C 
is commonly 
used to com- 
municate 
with 
terminals, 
modems, 
and other 
equipment 
up 
to 
a distance 
of 
50 
feet 
away. 
RS-422 
is a 
new 
interface 
that 
allows 
high-speed 
data 
transfers 
of up to 


4,000 
feet 
through 
differential 
lines 
that 
reduce 
noise 


such 
as 
crosstalk. 
The 
iSBX 
351 
module 
is the 
first 


expansion 
board 
to offer both interfaces. 


The 
iSBX 
351 module 
is programmed 
by a series 
of 
liD-read 
and 
-write 
commands. 
Table 
2 shows 
the 
110 
port 
assignments 
on the 
iSBC 
80/IOB 
board 
by way of 


explaining 
the code sequences 
in Table 
3 that 
run on it. 


The 
first routine 
in Table 
3, INIT, initializes 
the 8251A 
for asynchronous 
operation 
and 
programs 
the 
8253 
to 


generate 
a baud 
rate 
of 9,600. 
XMIT takes 
a character 
from 
the 
C register 
of the 
8080A 
and 
sends 
it to the 
Usart 
for transmission. 
RECV gets a character 
from 
the 


Usart 
and places 
it in the accumulator. 
Note 
that 
in both 
data-transfer 
routines 
the Usart 
status 
register 
is check- 
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ed to ensure 
proper 
operation. 


The iSBX 
350 programmable 
110 Multimodule 
board 
provides 
24 
general-purpose 
110 lines 
(or 
three 
8-bit 
ports) 
via a standard 
50-pin 
edge 
connector, 
giving 
the 


iSBC 
80/ IOB a total 
of 72 I/O lines. 
The 
8255A 
is the 


only 
LSI component 
on the 
board, 
and 
six sockets 
are 


provided 
for line drivers 
or terminators, 


Two 
bidirectional 
inverting 
4-bit 
bus transceivers 
are 


provided 
for one of the three 
ports; 
sockets 
for the other 


two are 
TTL-compatible, 
allowing 
the 
use of inverting, 


noninverting, 
or open-collector 
drivers. 
When 
either 
of 


these 
other 
two ports 
is used 
as an input, 
the 
lines 
may 


be terminated 
either 
with 
I-kilohm 
pullup 
resistor 
packs 


or with 220/330-ohm 
pullup/pulldown 
resistors. 


TABLE 
1 
,SBX 351 SERIAL 
INPUT/OUTPUT 
BOARO'S 


BAUO 
RATES AND 
INTERVAL 
TIMES 


Minimum 
values 
Maximum 
values 


Baud 
18.75 bauds 
64 kilobauds 


generator 
(limited 
by 8251A) 


Single timer 
1.63 ~s 
428 ms 


Dual cascaded 
3.26 ~s 
7.8 h 


timers 


Universal 
data port 
Fa, F2, F4, or F6 
Command 
Mnemonic 
synchronous! 
type 
asynchronous 
control port 
Fl,F3,F5, 
or F7 
receiver-tra nsmitter 
32-bit 
SADD 


Timer 
counter a 
F8 or FC 


counter 1 
F9 or FD 
32-bit 
SSUB 


counter 2 
FA or FE 


control port 
F B or F F 
32'bit 
SMUl 


32-bit 
SDIV 


TABLE 
3 
SERIAL 
INPUT /OUTPUT 
ROUTINES 


INT: 
MVI 
A, 
95 
Mode word to 8253 counter 2 


OUT 
OFB 


MVI 
A,8 
Divide value to 8253 counter 2 


OUT 
OFA 


MVI 
A, 
OFE 
Mode word to 8251 A Usart 


OUT 
OFT 


MVI 
A, 
27 
Command word to 8251 A 


OUT 
OFT 


RET 


XMIT: 
IN 
OFT 
Check Usart status to make sure it's 
ready to transmit a character 


ANI 
01 


JZ 
XMIT 
Loop until ready 


MOV 
A, 
C 
Get data character 


OUT 
OFO 
Send it 


RET 


RECV: 
IN 
OFT 
Check Usart status to see if a new 


character has been received 


ANI 
02 


JZ 
RECV 
Loop until data is available 


IN 
OFT 


ANI 
38 
Check framing, overrun, and parity 


error bits 


JNZ 
ERROR 
Jump to an error handler If there 


are any problems 


IN 
OFO 
Get data 


RET 


The 
iSBX 
350 
module 
supports 
all 
three 
8255;\ 
modes: 
basic 
1/0, strobed 
1/0, and 
strobed 
bidirectional 


bus 
1/0. 
Several 
of the handshaking 
signals 
arc available 
as interrupt 
sources, 
and an additional 
external 
interrupt 


may be brought 
in via the edge connector. 


Programming 
this board 
is as simple 
as programming 
the 
8255As 
on the 
iSBC 
80/10B 
itself. 
First, 
a mode 
word 
is written 
to the control 
port 
to specify 
the opera- 


tional 
mode 
for each 
port. 
Data 
transfer 
may then begin, 


in the form of I/O-read 
or -write 
operations_ 
The 
iSBX 
332 
module 
is an 
accurate 
32- or 
64-bit 
floating-point 
processor 
that 
performs 
arithmetic 
opera- 


tions in accordance 
with the proposed 
IEEE floating-point 
standard. 
It uses the 8232 floating-point 
processor. 
The 
math 
module 
uses one data 
format 
that 
has two 
word 
lengths 
of 
32 
or 
64 
bits. 
The 
board 
will 
add, 
subtract. 
multiply, 
and 
divide 
for 
both 
word 
lengths. 
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54·bit 
DADD 


54·bit 
DSUB 


64-bit 
DMUl 


54-bit 
DDIV 


ClR 


32-bit 
CHSS 


54-bit 
CHSD 


32·bit 
PTOS 


54-bit 
PTOD 


32·bit 
POPS 


54-bit 
POPD 


32-bit 
XCHS 


Table 
4 shows the instruction 
mnemonics 
and 
functions, 


as well as the positions 
in the stack 
(top of stack 
or next 
on stack) 
the operands 
and results 
occupy. 


The 8232 
runs at 4 MHZ 
for maximum 
throughput. 
A 


multiplication 
of two 
32-bit 
quantities 
takes 
about 
50 


microseconds, 
excluding 
data 
entry 
and 
retrieval. 
In 
addition, 
two interrupts 
signal 
the base-board 
processor 
of com plet ion of a n opera tion or a n error. 


Floating-point 
math 


The 
two 
word 
lengths 
of the 
floating-point 
standard 
were chosen 
for the highest 
speed 
and accuracy. 
If speed 


is 
the 
primary 
objective, 
the 
32-bit 
format 
gives 
a 


dynamic 
range 
of approximately 
10-38 to 10+38, 
If range 


and 
accuracy 
are 
reljuired, 
the 
64-bit 
format 
spans 
in 
excess 
of 
10+300 
to 
10-300. 
This 
wide 
dynamic 
range, 
in 


conjunction 
with 
highly 
accurate 
rounding 
algorithms, 


renders 
the 
iSBX 
332 
module 
ideal 
for scientific 
prob- 


lems and 
other 
applications 
requiring 
high 
speed, 
accu- 


racy. and range. 
D 


MULTIPROCESSING SYSTEM MIXES 
8- AND 16-81T MICROCOMPUTERS 


Combining 
different 
single-board computers on a single 
bus and assigning 
to each the tasks most suited 


enable a cost-effective multiprocessing 
system configuration 


with improved throughput 
and reliability 


Two or more single. board computers 
can share a com· 


mon 
system 
bus 
to 
provide 
improved 
performance, 
reliability, 
and 
cost·effectiveness 
in 
medium 
to 
large 


scale applications. 
Interfacing 
multiple 
computers 
across 


a system 
bus 
affords 
a dual·bus 
architecture 
in which 


global system traffic is isolated 
from 
local traffic on the 
board 
buses. 
This 
allows 
a straightforward 
design 
of 


modular 
multiprocessing 
systems that combines 
different 


computer 
boards, 
and allocates 
to each that 
portion 
of 


the overall system function 
to which it is best suited. 
In a typical 
design, 
8· and 
16·bit 
single·board 
com. 


puters 
(SBCS) communicate 
across a system bus to ser· 


vice an application 
that 
requires 
both 
realtime 
data 
ac· 


quisition 
and 
extensive 
signal 
processing. 
Partitioning 


system tasks and assigning 
each to the appropriate 
SBC 


optimizes performance 
without adding components. 
Dual. 


port memory 
provides 
a convenient 
way to synchronize 


processes 
on different 
SBCs. Because 
most 
system 
func· 


tions are isolated 
on one SBC,reliability 
and throughput 


are increased, 
and implementation 
is facilitated. 


In earlier 
SBCdesign, 
the fundamental 
goal was to pro· 


vide a bo'ard containing 
all the resources 
required 
for a 


large variety 
of microprocessing 
applications. 
A typical 


processor 
board 
supplies 
an 8080A 
processor, 
4k bytes 


of random 
access memory 
(RAM), 
sockets for up to 8k 


bytes of erasable 
programmable 
read 
only memory/read 
only memory 
(EPROM/ROM), 
a serial input/output 
(I/O) 


interface, 
48 parallel 
I/O lines, three timer/counters, 
and 
eight 
levels 
of priority 
interrupt. 
With 
this 
hardware 
configuration, 
many 
small 
applications 
can 
be 
served 
with no need for additional 
memory 
or digital 
logic. 


Because 
larger 
applications 
require 
additional 
rt'- 


sources, 
an 
external 
bus 
structure 
\\ as 
defined. 
The 


Ml 
I.TIBlSnl 
system 
bus was de~i~ned 
for communication 


hetween 
StlCs and system expansion 
hoards. 
Address, 
data, 


and 
handshake 
lines 
were 
defined 
for 
memory 
and 
1'0 
transfers 
between 
SACSand 
expansion 
hoards. 
There 
are 
bus 
expansion 
boards 
for 
system 
expansion 
in areas 
of 


IIAM 
and 
nOM 
stora/(e, 
serial 
and 
parallel 
I 
0, 
analo;.!: 


I '0, and 
peripheral 
controllers. 
In Fi:r ], two huses interconnect 
a system 
\\ ith an 
SHe 
and 
two 
expansion 
boards. 
An 
onhoard 
hus 
aCCf"sse~ 
local 
re~ources, 
and the system 
bus 
a('('e~se~ 
r..dohal 
rt"- 
sources. 
A key adv'anta/(e 
of this structure 
is that 
an SBe 
may not require 
the system 
bus for a lar;.!:e portion 
of it" 
memory 
or I 0 transactions. 
In mnny 
applications, 
les:-i 
than 
I()'; 
of the 
time 
is taken 
hy system 
bus 
acce",e". 
The lar/(e amount 
of potential 
system 
hus capacity 
make" 
this 
architecture 
a natural 
candidate 
for multiproce"in;.!: 


applications. 
As additional 
SBes are 
included 
in the sys- 
tem, 
the 
incremental 
amount 
of 
system 
hus 
hand\\idth 


required 
is usually 
small. 


Certain 
system 
applications 
benefit 
from 
usin/( more 
than 


a single 
SBC. Motivations 
for constructing 
multipro('essjn~ 
systems 
with StlCS include: 


Resource 
sharinl:. 
In a multiprocessing 
system 
desi/(ned 
around 
the 
resource 
sharing 
concept, 
two or 
more 
pro- 


cessor 
boards 
share a common 
resource, 
such as a hig-h 


MEMORY 


EXPANSION 
BOARD 


Fig 1 Single SBC system with 
two 
expansion 
boards. 
CPU 


uses 
data 
path 
1 to 
access 


local 
memory 
and 
I/O, 
and 


data 
path 2 to access 
expan- 


sion boards on MULTIBUS sys- 
tem bus 


110 


EXPANSION 


BOARO 


MULriBus'· SYS~~ 
---- 
----~ 


speed 
mathematics 
board 
or 
a 
peripheral 
controller. 


These 
hoards 
perform 
independent 
functions 
with 
no 


relationship 
to 
one 
another 
except 
for 
the 
shared 
re- 
source. 
Lo\\ 
cost 
is the 
obvious 
motivation 
for 
using 
a 
resource 
sharing 
multiprocessing 
configuration. 
If 
two 


processor 
hoards 
share 
the 
same 
diskette 
controller, 
for 
example, 
oV'erall system 
costs 
are 
considerably 
reduced. 


Enhanced 
s~'ste/ll throughput 
and performance. 
In many 


applications. 
sif!nificant 
improvements 
in 
performance 


Inny be achie\"ed by using 
more 
than one 
processor 
in 


the ~y~tem. Two 
\\ays 
of allocatin~ 
or partitioning 
sys· 


telll functions 
amon/( 
multiple 
processors, 
such 
as pipe- 


line and parallel 
partitioning, 
are sho\\ n in Fig 2. In pipe- 


line 
parlitioning. 
system 
functions 
Itasks I are 
divided 
am on;.!:sev'eral 
processors_ 
so that 
data 
110\\ 
through 
the 


"y"tem 
is primarily 
serial. 
[ach 
processor 
performs 
its 


portion 
of 
system 
functions. 
and 
then 
calls 
upon 
an- 


other 
processor 
to perform 
another 
set. 
An example 
of 
pipeline 
partitioning- 
is 
\\hen 
one 
processor 
performs 


data 
acquisition 
and 
buffering, 
while 
a second 
uses 
the 


data to perform 
dip;ital signal 
processing. 


Parallel 
partitioning 
allocates 
system 
functions 
among 


~f'\'eral processors 
in such a way that each processor 
per· 


forms 
a separate 
system 
task 
in parallel. 
An example 
is 


a sy~tem 
\\ here 
one 
processor 
performs 
an 
industrial 
proceS" 
control 
loop, 
\\hile 
another 
monitors 
and 
con- 


t !'ols a \ arying IJi.Hameter,such as temperature. 


Fe\\ 
systems 
mal' 
he characterized 
as totally 
parallel 
or 
pipeline 
partitioned, 
but 
designating 
systems 
in this 


manner 
can 
often 
be 
helpful 
during 
the 
system 
design 
pha"e_ 
particularly 
\\ hen 
interprocessor 
communication 
software is heing designed. 


iIfodularlr 
cOllfigu",d 
systems. 
A primary 
design 
goal, 


particularly 
in systems 
that 
are produced 
in low volume, 


is often 
flexibility 
of system 
configuration. 
Using 
modu· 


larly 
configured 
systems, 
independent 
hardware 
and soft· 
ware 
modules 
are 
designed 
and 
implemented 
with 
indi- 


vidual 
processors 
or 
intelligent 
slave 
boards. 
When 
a 
particular 
configuration 
is required, 
the system 
designer 


selects the necessary 
hardware 
and software 
modules 
and 


combines 
them 
with 
interprocessor 
communication 
soft- 


ware. 
Shortened 
system 
development 
time, 
simple 
debug- 


ging, 
and 
a convenient 
upgrade 
path 
for 
system 
expan- 
sion are the benefits 
of such a technique. 
High 
reliability. 
Multiprocessing 
may 
be used 
to isolate 


system 
tasks 
on 
individual 
processors 
in 
applications 
where 
a hi/lh 
de/lree 
of reliability 
is a requirement. 
If 


a processor 
fails, 
the remainder 
of the system 
continues 
to operate. 
Redundant 
designs, 
where 
a second 
processor 


may 
be dynamically 
assigned 
to perform 
the 
functions 
of a disabled 
processor, 
are a possibility. 


Multiprocessing With 
Single-Board Computers 


The 
MULTIBUS 
architectural 
design 
facilitates 
multiproces- 


sing 
because 
multiple 
bus 
masters 
are 
accommodated, 
bus 
masters 
generate 
and 
acknowledge 
bus 
interrupts, 


and 
dual-port 
memory 
and 
intelligent 
slave 
architecture 


can be implemented. 


Multiple Bus Masters 


A bus 
master 
is a dynamic 
board 
that 
takes 
control 
of 


the bus by asserting 
address 
and control 
lines. 
Only 
one 
bus 
master 
may 
control 
the 
bus 
at any 
given 
moment. 


Examples 
of bus masters 
include 
single-board 
computers 


Fig 
2 
Pipeline 
and 
parallel 


partitioning. 
Single 
processor 


A performs tasks X. Y. and Z. 
Pipeline 
partitioning 
among 


three 
processors 
allows 
pro- 


cessor 
B to 
perform 
task 
X 


and 
pass 
result 
to processor 


C; 
processor 
C 
to 
perform 


task 
Y 
and 
pass 
result 
to 


processor 
D; and processor 
D 


to perform 
task Z. Each 
pro- 


cessor 
except 
first must wait 


for 
input 
data 
generated 
as 


output from another processor. 
Parallel 
partitioning 
allows 


each 
processor 
to perform 
its 


task independently 


and 
direct 
memory 
access 
(DMA 
I 
controllers. 
A 
bus 


slave is a passive 
element 
on the bus that does not assert 
address 
and control 
lines. Examples 
of hus slaves 
include 


memory 
or 
J 
0 expansion 
boards 
and 
intelligent 
slaves. 
Several 
control 
lines exist 
on the bus so that 
potential 
bus 
masters 
can 
exchan!,:e 
control. 
These 
control 
lines, 


plus 
lo!,:ic on 
the 
master 
boards, 
implement 
a priority 


scheme 
in which 
the 
highest 
priority 
master 
requesting 


the bus ohtains 
control. 
There 
are t\\O priority 
resolution 
schemes 
for exchange 
of the bus, serial 
and 
parallel. 
Us- 
ing serial 
priority 
resolution, 
there 
may 
be up to three 


bus masters 
in the system: 
the parallel 
technique 
allows 


up to 16. A bus master 
is al\\ ays !,:iven the opportunity 


to complete 
a bus transaction 
before 
being 
preempted 
by 


a higher 
priority 
master. 
In addition, 
bus 
masters 
may 


retain 
control 
of the bus by "locking" 
the bus. 
The 
bus 


lock 
feature 
is required 
when 
a master 
must 
have 
ex- 
clusive 
control 
of the 
bus 
for such 
functions 
as testing 


and 
selling 
soft\\are 
semaphores 
and 
completin!,: 
opera- 


tions involvin!\ 
I/O devices. 
Since 
SBCS 
have 
extensive 
onboard 
resources, 
system 
bus transactions 
are not required 
for all I/O and memory 


accesses. 
Depending 
on the application 
and system 
desi!!:n, 


multiple 
bus 
master 
svstems 
with 
a 
small 
number 
of 


transactions 
can 'be co;,figured. 
The 
system 
design 
goal 


is to use onboard 
resources 
whenever 
possible. 
Frequently 


executed 
or 
time 
critical 
code 
should 
be stored 
in 
on- 


hoard 
memory 
to minimize 
system 
bus 
accesses 
and' to 


avoid 
delays 
while 
contending 
for 
the 
bus. 


Interprocessor 
Interrupts 


Ei!!:ht interrupt 
lines exist on the system 
bus. In addition 


to interrupts 
from 
I/O 
slave 
boards 
or 
DMA 
controllers, 


these 
interrupt 
lines 
can be used 
for communication 
be- 
tween 
master 
SBC boards_ 
Individual 
master 
boards 
may 
either 
generate 
interrupts 
or be interrupted 
from 
one or 


more 
of the interrupt 
lines. 
Interprocessor 
interrupts 
pro- 


vide 
a fast 
and 
effective 
way 
for 
multiple 
SBCs to com- 


municate 
over the system 
bus. 


Dual-Port Memory 


Single· board 
computers 
have been designed 
with onboard 


RAM containing 
two access 
ports. 
Dual 
access 
ports 
per- 


mit the onboard 
cpu to access the RAM directly 
using 
the 
on board 
bus. 
Other 
SBCs also 
access 
the 
RAM using 
the 


system 
bus. The 
amount 
of memory 
available 
for system 


bus access may be selected 
from 
all memory 
accessible 
to 
no memory 
accessible, 
in increments 
of one-half 
or one- 


quarter 
of available 
memory 
size. 
This 
ability 
to block 


RAM access 
from 
the 
system 
bus 
provides 
memory 
pro- 
tection 
for 
data 
and 
code 
stored 
in those 
nonaccessible 
areas 
of the dual-port 
RAM. Fig 3 illustrates 
an example 
of two SBCs accessing 
the dual-port 
memory 
of one SBC. 


Two 
important 
benefits 
are gained 
by using 
the dual- 


port architecture. 
First, 
in a multiple-processor 
system, 
if 


two 
processors 
communicate 
through 
shared 
memory, 
only 
one must 
access 
the memory 
using 
the system 
bus, 


and the amount 
of system 
bus traffic may be significantly 
reduced. 
Second, 
in a multiprocessor 
configuration 
where 
limited 
RAM storage 
is 
required, 
a 
separate 
memory 
board 
is not 
needed. 
Such 
small 
systems 
have 
all 
the 
required 
system 
bus-accessible 
memory 
on one or more 
of the SBCs. 


Intelligent Slave Architecture 


To distribute 
intelligence 
in larger 
systems, 
the intelligent 


slave 
concept 
was 
developed. 
An 
intelligent 
slave 
is 
a 


board 
that contains 
a CPU, some dedicated 
I/O capability, 


and 
a dual-port 
RAM for 
interfacing 
to the 
system 
bus. 


For 
example, 
the 
iSBC 5441''' intelligent 
communications 


controller 
contains 
an 
8085A 
processor, 
four 
8251A 
serial 
I/O 
devices 
universal 
synchronous/asynchronous 


receiver/transmitters 
(USARTS), 12 levels 
of priority 
in- 


terrupt, 
and 16k of dual-port 
RAM. All communication 
be- 


tween a master 
processor 
board, 
such as an iSBC86/12A 
T 
>l 


board, 
and 
the 
544 takes 
place 
using 
the 
544 
dual-port 


RAM (Fig 
4). 
The 
8085A 
processor 
does 
not 
have 
the 


capability 
of taking 
control 
of the system 
bus 
(becoming 


a bus master) 
and accessing 
other 
system 
resources. 


The 
544 
board 
was 
designed 
to 
operate 
using 
only 


onboard 
resources. 
The master 
SBCin the system 
transfers 


blocks 
of data 
and 
parameters 
to or from 
the 544 using 


the on board 
dual-port 
RAM. To 
facilitate 
communication 


with 
the 
544, 
an 
interrupt 
occurs 
when 
a master 
SBC 


writes 
into 
the 
lowest 
byte 
of memory 
of the 
dual-port 
RAM. The 
intelligent 
slave board 
can 
interrupt 
a master 
SBC by 
asserting 
one 
of the 
system 
bus 
interrupt 
lines 


with 
an I/O instruction. 
The 
address 
space 
occupied 
by 


the dual-port 
RAMmay be set anywhere 
within 
1M bytes: 


20 address 
bits are decoded. 
Primary 
advantage 
of intelligent 
slave 
architecture 
is 


the ease with which 
multiprocessing 
applications 
may 
be 


implemented. 
The 
intelligent 
slave 
may 
be sent 
a buffer 
of data 
and 
commands 
with 
an 
interrupt 
occurring, 
via 
a write to the lowest byte of memory, 
as a start 
command. 


The master 
SBC may continue 
operation 
with 
other 
func- 


tions 
to be notified, 
via 
an interrupt 
or a status 
byte 
in 
dual-port 
RAM, when the slave has completed 
a task. Since 


the intelligent 
slave may 
not access 
system 
resources 
via 


the system 
bus, no interference 
with 
the master 
SBC can 
occur. 


MULTIBUS 
ACCESSIBLE 


MULTI 
BUS 
ACCESS 
BLOCKED 


F g 3 
Dual-port memory archi- 


tecture. 
8086 
microprocessor 


on 86/12A 
uses dual-port con- 


troller to access 
onboard 
RAM. 


808SA on 80/05 
accesses 
this 
pame RAM across 
system bus. 


Different 
configurations 
allow 


808SA 
access 
to 
part 
or 
all 


of dual port memory 


The iSBC86/12A 
single-board 
computer' 
has many 
of the 
architectural 
features 
of B-bit hoards 
(serial 
and parallel 
I/O, 
multiple 
interrupt 
levels, 
and 
timer/counters 
I but 
includes 
a 
5-MHz 
8086 
microprocessor 
and 
larger 


amounts 
of 
R~M and 
El'flOM/ROM storage. 
The 
16-hit 


B086 permits 
byte 
and 
word 
transfers, 
hardware 
multi· 
ply/divide, 
1M-byte 
addressahility, 
extensive 
string 
ma- 


nipulation 
instructions, 
and 
many 
other 
features. 
The 


B6/12A 
contains 
.~2k bytes of dual 
port 
flAM and sockets 
for up to 16k bytes of EPflOM/ROM, douhling 
the memory 


availahle 
on previous 
hoards. 
If more IIAMor El'flOM/IIOM 


storage 
is required, 
memory 
expansion 
modules 
permit 


douhling 
RAM and/or 
EI'IIOM/ROM storage 
to 64k 
bytes 
of RAM and ~2k bytes 
of El'flOM/flOM. 
Memory 
expansion 
modules 
are 
small 
printed 
circuit 


boards 
that attach 
to the B6/12A 
board 
using 
sockets 
and 


nylon 
holts. 
Use 
of 
the 
expansion 
modules 
is 
advan- 


tageous 
from 
a price/perfoqnance 
point 
of view. 
Price 


of either 
of the memory 
expansion 
modules 
is significant- 


ly less than 
that 
of an 
e«uivalent 
separate 
memory 
ex- 


pansion 
hoard 
with 
its 
own 
system 
hus 
interface 
and 


support 
circuitry. 
Memory 
expansion 
modules 
als6 offer 


higher 
performance 
since 
it is not 
necessary 
to use the 
system 
hus 
for 
memory 
transactions. 
All 
transactions 


take 
place 
using 
the 
onboard 
bus 
with 
no 
additional 


wait states or bus contention. 


The 
BOB6 microprocessor 
performs 
8- or 16-bit transfers 
to or from 
memory 
or I/o devices. 
When 
a byte 
(B.bit) 
transfer 
is requested 
from 
an even address, 
data 
are pre- 


Fin 4 
Intelligent 
slave archi- 
tecture. 
86/12A 
and intelligent 
slave board 
544 communicate 


using dual-port 
RAM 


sented 
to the microprocessor 
on its low order 
data 
lines, 


DO through 
07. 
When 
a byte 
transfer 
is requested 
from 


an 
odd 
address, 
data 
transfer 
must 
occur 
on 
the 
high 
order 
data 
lines, 08 through 
015. 
When 
a 16-bit 
(word) 


transfer 
is requested, 
data 
are transferred 
on all 16 data 


lines, 
DO through 
D15. 
When 
an 
B-bit 
microprocessor 


iH080A 
or 8085A) 
is used, 
however, 
all byte 
transfers 


must 
take 
place 
on data 
lines 
DO through 
07, 
the 
only 


lines available. 


To maintain 
compatibility 
between 
boards 
with 
8-bit 


and 
16-bit processors, 
a system 
bus transfer 
protocol 
has 


been 
developed 
where 
all 
byte 
transfers, 
regardless 
of 


whether 
from 
an 
odd 
or 
even 
address, 
take 
place 
on 


the 
low order 
system 
bus 
data 
lines, 
DATO/ to 
DAT7/; 
word 
transfers, 
however, 
use all 16 data 
lines, 
DATO/ to 


DATFl 
To 
accomplish 
these 
byte 
transfers, 
an 
8-bit 


buffer is used on 16-bit master 
and slave boards 
for trans- 


ferrin!; 
data 
from the high 
order 
data 
lines on the board 


to the low order 
data 
lines of the system 
bus. 
An 
addi- 


tional 
signal 
line, 
byte 
high 
enable, 
(BHENj) 
indicates 


whether 
a word transfer 
is taking 
place on the high order 
and 
low order 
data 
lines 
or 
whether 
a byte 
transfer 
is 


takin!; 
place 
only 
on 
the 
low 
order 
data 
lines. 
Fig 
5 


illustrates 
8- and 
16-bit 
transfers 
and 
the use of the ad- 


ditional 
buffer 
for transferring 
the signal 
to or from 
the 


hi!;h order 
data byte. 


A data 
acquisition 
and 
signal 
processing 
system 
design 


demonstrates 
the capabilities 
of a multiprocessing 
system, 


where 
improved 
performance 
is mandatory. 
General 
ap- 


plication 
of 
the 
system 
is power 
spectrum 
analysis 
of 
vihration 
and acoustic 
signals. 
Application 
areas 
for such 


MULTIBUS 
DEVICE 


CASE 
MULTIBUS 


To4 
BHENI 
ADROI 
TRANSFER 
BYTE 
DATA 
PATH 
TRANSFERRED 


DATOI- 
DAT71 


A. 
H 
H 
a-BIT 
EVEN 
DATOI- 
DAT71 


Fig 5 
Three 
mechanisms 
for 


DATOI- 
DAT71 
byte 
and 
word 
transfers. 
All 


byte 
transfers 
use 
OATO to 


B. 
H 
B-BIT 
ODD 
OAT? Only word transfers 
use 
DATOI· 
DAT71 
high order 
bus lines OATB to 


DAT8I· 
DATFI 
OATF. Slash 
(I) after 
name 


indicates 
active 
low signal 


DATOI· 
DAT71 


16·BIT 
EVEN 
c. 
H 
AND 
DATOI· 
DATFI 
ODD 


DAT8I· 
DATFI 


systems 
include 
vibration 
analysis 
in mechanical 
struc· 


tures 
such 
as electric 
motors, 
automobiles, 
aircraft, 
and 


buildinp;s, 
as 
well as speech, 
sonar, 
and 
low frequency 
radar 
analysis. 


Design 
objective 
is to monitor 
the condition 
of large 


electric 
motors. 
Power 
spectra 
of vibration 
signals 
from 


various 
points 
on the 
motor 
are 
calculated 
in order 
to 
detect 
bearin/!; 
wear 
and 
to predict 
an impending 
motor 


failure. 
Calculated 
power 
spectra 
are compared 
with 
ref· 


erence 
spectra, 
and, 
if thresholds 
in various 
regions 
of 


the spectra 
are exceeded, 
an operator 
alarm 
is activated. 
Information 
regarding 
the 
state 
of the 
motors 
and 
the 
reference 
spectra 
is stored 
on disc. 


The system 
monitors 
16 channels 
of analog 
input 
sig· 


nals 
generated 
by 
pairs 
of 
accelerometers 
mounted 
on 


each 
of eip;ht motors. 
Sampling 
and 
calculations 
for the 
two channels 
of a single 
motor 
are 
performed 
simulta- 


neously; 
then 
the next motor 
in sequence 
is monitored. 


Fast 
Fourier 
transform 
(FFT) 
of a buffer 
of samples 


from 
an 
analog 
to 
digital 
converter 
(ADC j 
performs 


POll er 
spectrum 
calculations. 
Real 
and 
imaginary 
parts 


of the 
nOT results 
are squared 
and summed 
to form a pow- 


er spectrum 
that is compared 
to the reference 
power 
spec- 


trum 
ill order 
to determine 
if the motor 
vibrations 
are 
within 
acceptable 
tolerances. 
A 
CIIT 
displays 
calculated 


and 
reference 
power 
spectra. 
At periodic 
intervals, 
data 


arc 
stored 
on disc 
for 
archivinp; 
the 
condition 
of each 


of the motors. 
If the motor 
spectra 
exceed 
the reference 


spectra, 
the 
CRT display 
and 
a control 
panel 
indicator 


alert the operator. 


System 
Hardware 


As shown 
in Fig 6, the 711 analog 
input 
board, 
contain- 


ing a 12·bit 
ADC, samples 
the 16 analog 
signals 
from 
the 


motors. 
The 80/05 
processor 
board 
drives 
the 711 analog 


board 
and handles 
all system 
data 
acquisition 
activities. 


The HO/OS contains 
an 80SSA 
CPU, 
512 bytes 
of 
RAM, 
up 


to 4k bytes of EPROM/ROM, 
a timer/counter, 
parallel 
and 
serial 
I/O lines, and four 
levels of priority 
interrupt. 
The 


86/12A 
board 
is the 
main 
system 
processor. 
The 
8086· 


based 
board 
performs 
all the signal 
processing 
functions, 


displays 
the spectra 
on the 
CRT, drives 
the system 
control 


panel, 
and transfers 
motor 
condition 
data 
onto disc using 


the 204 
single-density 
diskette 
controller. 


Increased 
system 
performance 
is the design 
motivation 


for using 
two processor 
boards. 
The 
86/12A 
board, 
with 


its 5 
MHZ 
8086 
CPU, 
16-bit 
multiply/divide 
capability, 


64k bytes of dual-port 
RAM, and 32k bytes of EPROM/ROM, 


is used 
for the mathematically 
intensive 
power 
spectrum 


calculations. 


The 
SO/OS 
processor 
board 
is 
used 
to 
offload 
data 


acquisition 
activities 
from the main 
processor. 
It assumes 


all the overhead 
of handling 
the 711 analog 
board. 
Sam- 


pling 
is performed 
at 2S0-/,s intervals 
using 
the onboard 


timer; 
data 
from 
the 
two channels 
are 
scaled, 
demulti- 
plexed, 
and stored 
in a buffer. 
The 8-bit processor 
board 


INTELLIGENT 
ANALOG 
SUBSYSTEM 
r-------- 
.---- 
--- --~_.-~-, ---, 
, 
, 


: 
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;' 
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Fig 6 
Data 
acquisition 
and 
signal 
analysis 
system. 
80/05 
drives 
711 to handle 
all data 


acquisition 
functions while 86/ 


12A performs 
signal 
analysis, 


operator 
interfacing, 
data stor- 
age, 
and 
data 
retrieval 
func- 


tions 


was cho:'en 
for this function 
because 
it had the necessary 


onboard 
resources, 
yet \\ as low in cost. Throughput 
per- 
formance 
improvements 
of up to 40'/< 
can 
be achieved 
using 
this 
2-processor 
approach. 


The 
3D 05-711 
combination 
assumes 
the 
role 
of 
an 
intelligent 
analog 
subsystem, 
when viewed 
by the 86, 12A 
processor. 
The 
S6/12A 
sends 
the 
80/0S 
commands 
via 


a parameter 
block, and the SO OS collects the data samples 
in buffers. 
When 
a buffer 
is complete, 
the 80; OS signals 


the 86/12A 
using 
the parameter 
block. 
Thus, 
the 80/0S 


acts 
as an intelli/!:ent 
DMA controller 
for the 711 board. 


Due 
to the 
lu/!:e 
RAM requirements 
of the 
system, 
the 


issc 
30(j"'" HAMexpansion 
module 
is used to increase 
RAM 


capacity 
to 64k 
bytes. 
Memory 
has 
been 
configured 
to 
make 
16k bytes 
of memory 
accessible 
to the system 
bus, 
\\ ith 
the 
remain in/!: 43k 
bytes 
reserved 
for 
use 
by 
the 


onboard 
8086 
and 
not accessible 
to the system 
bus. The 


amount 
of 36/12A 
dual-port 
RAl\! that 
is system 
bus 
ac- 


cessible 
may 
be configured 
in 16k increments 
from 
zero 


Ino memory 
accessible) 
to 64k 
Iall memory 
accessible). 


The parameter 
block 
used for interprocessor 
communica- 


tion 
and a pair 
of buffers 
used 
for storage 
of the analog 


samples 
are stored 
in the memory 
accessible 
to the 80/05. 


Memory 
not accessible 
to the 80/0S 
contains 
the data 
and 
buffers 
used 
for the 
calculated 
averaged 
power 
spectra, 


reference 
spectra, 
CRT displays, 
and 
disc 
data. 
The 
16 


bytes 
of the parameter 
block 
contain 
all information 
re- 


quired 
for 
communication 
between 
the 
two sscs 
in the 


system, 
including 
buffer 
addresses, 
status, 
size, 
sample 
rate, 
and 
start 
and 
end 
channel. 


Fig 
7 is' a Row diagram 
illustrating 
how buffer 
status 
bytes 
are 
used to synchronize 
the fiiling 
and 
processing 


of the 
data 
buffers. 
Each 
buffer 
may 
be in one 
of two 


states, 
FULL or EMPTY. Initially, 
both 
buffers 
are EMPTY. 


At initialization, 
the 80/0S 
fills buffer 
0, sets 
its status 
to FULL, fills buffer 
1, sets its status 
to FULL, and 
waits 


for buffer 
0 to become 
EMPTY. It then 
fills buffer 
0, sets 


its status 
to F LL, waits 
for buffer 
1 to become 
EMPTY, 


etc. 
Initially, 
the 86/12A 
waits 
for buffer 
0 to be FULL, 


processes 
it, sets its status 
to EMI'TY, waits 
for buffer 
1 


to be 
FULL, etc. 
Using 
this 
simple 
technique, 
the 
two 


processors 
synchronize 
each other 
with a minimal 
amount 
of overhead. 
The 
parameter 
block 
approach 
is used 
to provide 
a 


simple 
means 
for interfacing 
the two SSCs. At system 
in- 


itialization, 
the 3D/OS board 
needs 
only to know the base 


address 
of the parameter 
block. 
Once 
this 
is known, 
all 
other 
information 
required 
for 
the 
3D, OS to 
function 
properly 
is available. 
The 
end 
application 
and 
even 
the 


specific 
type 
of ssc 
that 
calls 
upon 
the 
80 OS for 
data 


samples 
remain 
irrelevant 
to the 80/0S. 
Driver 
software 


for 
the 3D/OS is therefore 
hi/!:hly modular 
and 
may 
be 


used in a \ ariety 
of applications 
and configurations 
\\ ith 


no changes required. 
A key 
capability 
of 
this 
system 
design 
is 
that 
the 


861l2A 
board 
does not use the system 
bus to access data 


samples, 
thus 
minimizing 
execution 
time 
for 
the 
highly 


iterative 
FFT computation. 
The 
80/0S 
processor 
takes 


the samples 
from 
the 
analog 
board 
and 
stores 
them 
di- 


rectly 
into the 86/12A 
dual·port 
memory. 
Therefore, 
ex- 
cept 
for 
occasional 
disc 
transfers 
by 
the 
36/12A, 
the 


30/ OS is the 
only 
processor 
usin/!: the 
system 
bus. 
This 


increases 
system 
throughput 
and 
eliminates 
contention 


for the system bus. 


Signal Processing 
Software 


The 
algorithm 
used 
for 
the 
FFT in this 
application 
is 


known 
as "time 
decomposition 
with input 
bit reversal."2 


l1sing 
this 
algorithm, 
an 
in-place 
FFT has 
been 
pro- 
grammed 
for an input 
frame 
size of 128 complex 
points. 


Sixteen-bit 
integer 
mathematics 
is used 
for 
all 
internal 
calculations 
of the FFT. The 36/12A 
board 
computes 
the 


128-point 
complex 
FFT in 
110 ms. 
Computation 
of the 


a\'eraged 
power 
spectra 
is performed 
using 
a double 
pre- 


WAIT 
FOR 
BUFFER 
F 
TO 
EMPTY 


SET 
STATUS 


OF 
BUFFER 
F = 
FULL 


WAIT 
FOR 
BUFFER 
P 
TO 
FILL 


SET 
STATUS 
OF 
BUFFER 


P = 
EMPTY 


Fig 7 
Synchronization 
of two SBGs. Buffer status 
bytes 
are 
used 
in shared 
parameter 
block. 
Simple semaphore 
mechanism 
is natural 
extension 
of double buffered acquisition 
technique 


clslOn integer 
format. 
The 16·bit integer 
real and imagi. 


nary 
values 
which 
result 
from 
the FFT are squared 
and 


summed 
to obtain 
a 32·bit 
power 
spectrum. 
Thirty·two 


frames 
of data 
are processed 
and summed 
to form 
the 
averaged 
power spectrum. 


Two reasons 
for the slow growth 
of multiprocessing 
have 


been the limited 
selection 
of SBCsand the relatively 
small 


application 
base. 
These conditions 
are changing 
rapidly 
due 
to the 
large 
number 
of SBCSnow available. 
These 
boards 
contain 
dual·port 
RAM 
and newer 
8· and 
16·bit 


cpus, and provide 
system designers 
with a comprehensive 
set 
of 
tools 
for 
tackling 
applications 
that 
require 
the 


power 
of multiprocessing. 
Thus, the SBCapplication 
base 
has grown significantly 
in recent years. 
The system 
application 
combines 
a low cost 8·bit SBC 
and 
a high 
performance 
16·bit 
SBC in a configuration 
designed 
for 
both 
data 
acquisition 
and 
signal 
analysis. 
The 8-bit 
SBC relieves 
the 16-bit SBC of all system 
data 
acquisition 
functions. 
Because 
the 
16-bit 
board 
spends 


full time processing 
data, 
system 
throughput 
can be in· 
creased by as much as 40'!< . 
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INTRODUCTION 


A large number 
Of microcomputer 
applications 
require 'the ability to respond to events in real time. 
RMX/80 
provides 
the 
system 
software 
around 
which you can build a real-time multitasking appli- 
cation on Intel SBC 80 Single Board Computers. 
In addition, 
RMX/80 increases the utilization 
of 


a Single Board Computer by allowing its resources 
to be shared among several tasks executing concur- 
rently. Synchronization 
of these multiple real-time 
tasks is handled by RMX/80, freeing you to con- 
centrate your major programming efforts on your 
application. 


This application note begins with an overview of 
RMX/80. Readers who are familiar with the mate- 
rial presented 
in the RMX/80 User's Guide may 
choose to skip to the next section, a description of 
how to use RMX/80 and the steps involved in 
using it by describing two applications. 


• An interrupt driven minimal te~lT\inalhandler 


for a CRT or Teletypewriter- 


• A closed-loop analog control subsystem utiliz- 


ing the Intel SBC 7 I I analog-to-digital board. 
Each example has diagrams illustrating 
the rela- 
tionships between its tasks and exchanges. These 
are useful tools in' conceptualizing 
the activities 


taking place in real time. Program listings of the 
applications 
are interspersed with text describing 
the application. 


, 
, 


Real-time systems provide the ability to control 
and respond to events occurring asynchronously 
in the 
physical wo~ld. Later in this application 


note, 
a process control 
application _is described 


that monitors and' controls the temperature within 
several chambers. The system controls the process 
by simply turning on and off a heat source. The 
system could also display the temperature 
on an 


operator's 
console and permit rptry 
of new set- 


point temperatures and error ranges. 


A single large program could have been used to 
perform 
the 
functions 
in a sequential 
manner- 


However, this approach may not permit an opera- 
tor to enter control variables at the same time the 
process 
is being 
monitored 
and 
controlled. 
In 


contrast, real4ime systems do not operate sequen- 
tially. A number of events may all be happening 
at the same time. This concurrence of events is a 
distinguishing characteristic 
of real-time systems. 


BASIC CONCEPTS 


There are basically three concepts that 
the user 


must master to effectively use RMX/80. The first 
is the task, an independent 
program which com- 


petes for resources within the system. The second 
concept is the message. Messages convey data and 
synchronization 
information 
between 
tasks. The 


third concept is the exchange. An exchange enables 
one task to send a message to another. As we will 
see later, the interaction 
between 
tasks and ex- 


changes enables the user to implement 
mutual 


exclusion, 
communication, 
and synchronization: 


Mutual 
exclusion 
is a technique 
that 
controls 
access to ~ shared resource such as an I/O device 
or a data structure. 


Task 


Under RMX/80, the u~~rc'odes a separate prpgram, 
known as a task, for each event. An arbitrary num- 
ber of these tasks execute concurrently 
and are 


subject to synchronization 
as required 
by their 
functions. Tasks share resources su<;;has data struc- 
tures and can communicate 
between themselves. 


Message 
1'1 


A message is a unit of communication 
betw~en 


tasks. Together with the exchange mechanism, it 
conveys information 
between 
tasks and can syn- 


chronize their operations. 


Exchange 


RMX/80 uses message exchanges for task-to-task 
comm'unication.An 
exchange is a pair of queues 


represented by a data structure at which messages 
are left by one task to be picked up by another. 
Tasks may send messages to an exchange, and may 
wait for messages at an exchange. A task which 
waits for a message may perform a timed or an 
untimed 
wait. A. timed -wait will terminate 
upon 


the receipt of a message or at the end of the speci- 
fied period of time, even if it has not received a 
message. When a task does anuntimed 
wait for a 


message it is guaranteed that the task will not exe- 
cute again until a message is available for it: A 
representation 
of the exchange data structure 
is 


shown in Figure I;, 


GENERAL CHARACTERISTICS 
In addition to the basie"concepts of tasks and ex- 
changes, several other 
general 'characteristics 
-of 


RMX/80 are relevant in this overview. 


System 
Time Unit 


RMX/80 
uses a system 
time unit that is the period 


of time between 
"ticks" 
of the system 
clock. 
The 


standard 
RMX/80 
system 
time 
unit 
is 50 
milli- 


seconds. 
The system 
time unit provides 
timing and 
user 
task 
scheduling. 
A task 
may 
wait 
at an ex- 


change 
for 
a specified 
number 
of 
system 
time 
units 
and 
then 
continue 
execution. 
A task 
could 


be 
written 
to 
generate 
messages 
at specific 
time 


intervals. 
Tasko/ waiting 
for 
the 
messages 
would 


then be scheduted 
according 
to those time intervals. 
, 


Message Producing/Consuming 
Tasks 


In general, 
tasks 
can be classified 
as message 
pro- 


ducing 
or message consuming 
tasks. The processing 


flow 
of these 
types 
of tasks 
are usually 
cyclic in 


nature 
and can be shown as follows. 


A consumer 
task waits for a message 
to be posted 


at a particular 
exchange 
and 
takes 
control 
of the 


processor 
only when 
it has received 
a message and 


no other 
tasks of higher 
priority 
are ready 
to exe- 


cute. 
The 
consumer 
task 
performs 
some 
action 


based 
upon 
the 
message 
and then 
simply 
resumes 


waiting 
until 
the next 
message is received. 
Usually, 
the 
consumer 
task 
acknowledges 
completion 
of 


its function 
by sending 
a response 
message to some 


other exchange 
associated 
with a task. 


A producer 
task 
initiates 
its function 
by sending 


a message 
to another 
exchange 
and then surrenders 


control 
of 
the 
processor. 
The 
task 
continues 
to 


wait 
until 
it receives 
a response 
to 
its 
message. 


Notice 
that 
the 
distinction 
between 
these 
types 


of tasks 
is relative 
since 
most 
tasks both 
produce 


and 
consume 
messages. 
However, 
the 
producer/ 


consumer 
concept 
helps 
clarify 
the 
general 
struc- 
ture 
of 
tasks-tasks 
are 
typically 
programmed 


loops. 
A producer 
task performs 
a function, 
sends 


a message, 
waits for a response, 
then loops back to 


begin 
again. A consumer 
task waits for a message, 


performs 
a function, 
sends a response, 
then 
loops 


back to wait again. 


Interrupts 


Hardware 
interrupts 
are treated 
as messages 
from 


peripheral 
devices 
for which 
a task can wait, 
as if 


the interrupt 
were a message from some other task. 


These 
messages 
arrive 
at 
particular 
exchanges, 


called interrupt 
exchanges, 
but are otherwise 
treated 


as described 
above. 
The 
system 
provides 
the abil- 
ity 
to mask 
particular 
interrupts 
so that 
no mes- 
sages ever arrive at a particular 
interrupt 
exchange 


associated 
with 
the masked 
interrupt. 
In the event 


that 
the overhead 
associated 
with 
turning 
an inter- 
rupt 
into 
a message 
is too high, the interrupt 
can 


be treated 
by the user directly 
via a user supplied 


interrupt 
service routine. 


Task States 


Tasks 
may 
exist 
in a number 
of states. 
A task is 


running 
if it actually 
has the 
processor 
executing 


instructions 
on its behalf. 
A ready 
task is one that 


could 
be running 
(any wait for a message 
or time 


period 
has 
been 
satisfied), 
but 
a higher 
priority 


task 
is 'currently 
running. 
A task 
is waiting 
if it 


cannot 
be ready 
or running 
because 
it is waiting 


at an exchange 
for a message. 
A suspended 
task is 


one 
that 
is not 
permitted 
to run 
or compete 
for 


system 
resources 
until 
it 
is resumed. 
The 
rela- 
tionships 
between 
the task states 
are illustrated 
in 


Figure 3. 


Priority 


Each task has associated 
with 
it a priority 
that 
in- 
dicates 
its 
importance 
relative 
to 
other 
tasks 
in 


the 
system 
and 
relative 
to the 
interrupts 
of peri- 
pheral 
devices. 
RMX/80 
schedules 
a task for exe- 
cution 
based 
on 
the 
task's 
priority. 
Whenever 
a 


decision 
must 
be made 
on which 
task 
should 
be 


run, the highest 
priority 
ready task is chosen. 
Each 


of the 
eight 
hardware 
interrupt 
levels has a set of 


priorities, 
one 
of 
which 
must 
be assigned 
to the 


task that 
services 
the interrupt. 
When an interrupt 


occurs 
that 
task 
is executed 
if it is the 
highest 


priority 
ready 
task. 
At the 
time 
a higher 
priority 


task 
preempts 
a 
lower 
priority 
task, 
RMX/80 


saves 
all the 
relevant 
information 
about 
the 
pre- 


empted 
task so it can eventually 
resume 
execution 


as though 
it were 
never 
interrupted. 
This process 


is known 
as a context 
save. 


NUCLEUS 
OPERATIONS 


The 
RMX/80 
nucleus 
provides 
several 
operations 


that 
you 
can access 
with 
programmed 
calls. Two 


basic 
operations 
are covered 
in this section 
(addi- 


tional 
operations 
are 
described 
in 
the 
RMX/80 


User's Guide): 


• 
RQSEND, 
send 
a message 
to 
an exchange 


• 
RQWAIT, 
wait for a message 
or time interval 


These 
two 
operations 
provide 
the 
capability 
to 


pass 
messages 
between 
tasks 
in a system 
running 


under 
RMX/80. 


Message Forma t 


The messages 
used by the send and wait operations 
to convey 
information 
between 
tasks 
are variable 


in length 
and 
contain 
the 
information 
shown 
in 


Figure 4. 


LINK 


LENGTH 


TYPE 
I 


HOME 
EXCHANGE 


RESPONSE 
EXCHANGE 


REMAINDER 


Fields 


I. LINK - 
a 2-byte 
field used to enter the mes- 


sage on a linked list at an exchange. 


2. LENGTH 
- a 2-byte 
field containing 
the total 


length 
of the message 
in bytes. 
The minimum 


message 
length 
is 5 bytes 
(LINK, 
LENGTH, 


and TYPE). 


3. TYPE 
- 
a I-byte 
field indicating 
the type 
of 


message. 


4. HOME 
EXCHANGE 
- 
an 
optional 
2-byte 


field containing 
the address of an exchange 
to 


which 
this message should 
be sent when it has 


no further 
use. This field is very useful in im- 


plementing 
and managing 
a pool 
of messages. 


5. RESPONSE 
EXCHANGE 
- 
an 
optional 


2-byte 
field 
containing 
the 
address 
of an ex- 
change 
to 
which 
a logical 
response 
to 
this 


message 
should 
be sent. 
This field is intended 


to 
specify 
the 
exchange 
at which 
a sending 


task 
is 
waiting 
for 
an 
acknowledgement 


message if one is needed. 


6. REMAINDER 
- 
an 
optional 
field 
of 
arbi- 


trary 
length 
that 
may 
contain 
any 
data por- 
tion of the message. 


Sending a Message to an Exchange 


The 
RQSEND 
operation 
enables 
a task 
to post 
a 


message 
at an exchange. 
When you send a message 


to an exchange, 
RMX/80 
actually 
posts 
only 
the 


address 
of 
the 
message 
at the 
exchange, 
not 
the 


body 
of the message. 
RMX/80 
avoids the overhead 


required 
to 
move 
an 
entire 
message 
to 
an 
ex- 


change. 
Thus 
it is possible 
to queue 
a number 
of 


messages 
at the same exchange 
with little overhead 


in either 
execution 
time or memory 
requirements. 


When 
a task 
sends a message 
to an exchange, 
sev- 


eral functions 
are performed. 


• 
The 
message 
is placed 
on 
the 
specified 
ex- 


change. 


• 
If there 
are one or more 
tasks waiting 
at the 


exchange, 
the 
first 
task 
is given the message 
and is made ready. 


• 
If 
a 
higher 
priority 
task 
is 
thereby 
made 
ready, 
the 
sending 
task 
loses 
control 
until 


it 
once 
again 
becomes 
the 
highest 
priority 
ready task. 


After 
a message 
is sent to an exchange, 
it must not 


be modified 
by the sending 
task. A task which then 


receives 
the 
message 
by 
waiting 
at the 
exchange 
where 
the message 
has been posted 
is free to modi- 


fy the message. 
The format 
of the RQSEND 
opera- 


tion is as follows. 


Message exchanges 
are defined 
by the user, and are 
normally 
addressed 
symbolically. 
For 
example, 
the exchange 
used to pass readings 
from an analog- 


to-digital 
(A/D) 
task 
might 
be named 
ATODEX. 
The reading 
itself 
could 
be contained 
in a message 
with 
the 
name 
RDNG. 
Thus, 
a typical 
call for a 


send 
in 
a PL/M 
program 
might 
be 
as follows: 


CALL 
RQSEND (.ATODEX,.RDNG) 
; 


The 
call 
procedure 
in 
assembly 
language 
is 
as 
follows. 


The assembly 
language 
rules for passing parameters 
to RMX/80 
are the same as for passing parameters 
to a PL/M procedure 
called 
from 
an assembly 
lan- 


guage 
module. 
For 
2-byte 
parameters, 
the 
first 


parameter 
is passed 
in the 
Band 
C registers; 
the 


second 
parameter 
is passed in the D and E registers. 


Waiting for a Message or Time Interval 


The 
RQWAIT 
operation 
causes 
a task to wait for 


a message 
to arrive 
at an exchange. 
It is also pos- 


sible to delay 
execution 
of a task when no message 


is anticipated 
for 
the task. 
The 
task simply 
waits 
for the desired 
time 
period 
at a message 
exchange 


where 
no message 
is ever sent. When a task waits 


for 
a message 
at 
an exchange 
several 
operations 


are performed. 


• 
The 
task 
is made 
to wait 
until 
a message 
is 
sent 
to 
the 
specified 
exchange, 
or until 
the 


time limit has expired. 


• 
When 
a message 
is available, 
its 
address 
is 
returned 
to the task. 


• 
If 
the 
time 
limit 
expires 
before 
a message 


becomes 
available, 
a system 
TIME$OUT 
mes- 
sage is returned 
to the task. 


The 
time 
limit 
is entered 
as some number 
of sys- 


tem 
time 
units 
(50 milliseconds); 
a I-second 
wait 


is equal 
to 20 time 
units. 
If zero 
is specified 
the 


wait 
is not 
timed, 
producing 
an indefinite 
wait 


until 
a message 
is actually 
sent 
to the 
exchange. 


Note 
that 
a specified 
wait 
of five time units 
may 
sometimes 
only 
produce 
an 
actual 
wait 
of 
four 


time 
units. 
This 
can 
occur 
if you 
enter 
a wait 


immediately 
before 
the 
clock 
"ticks." 
In 
this 
case the count 
would be decremented 
immediately 
after 
entering 
the 
wait. 
Only 
four 
full time 
unit 


periods 
would 
lapse 
before 
completion 
of 
the 
wait. Thus a user who wishes to ensure 
that at least 
five time 
units 
are spent 
in an asynchronous 
wait 


must 
specify 
six time units 
in the wait operation. 
A task 
which 
waits 
synchronously 
to the 
system 
clock, 
Le., 
performs 
repetitive 
timed 
waits, 
does 


not 
have 
this 
problem 
because 
a new wait is exe- 
cuted 
following 
a tick 
that 
satisfied 
the 
previous 
wait. 
The 
following 
are 
typical 
calls 
for 
the 


RQWAIT 
operation. 


The 
RQWAIT 
procedure 
returns 
an address 
value 


which is the address 
of a message. 


The 
address 
of 
a message 
is returned 
in the 
HL 


register 
pair. 


Send - Wait Interaction 


To a large extent, 
the power 
of RMX/80 
as a pro- 


gramming 
tool 
is 
derived 
from 
the 
interaction 
between 
send 
and 
wait. 
The 
interaction 
includes 
three multi-tasking 
operations. 


• 
Communication 


• 
Synchronization 


• 
Mutual 
Exclusion 


In describing 
these 
operations, 
a graphic 
notation 


for 
diagramming 
tasks, 
exchanges, 
and 
their 


interaction 
(send 
and 
wait 
operations) 
is useful. 


The 
notation 
is described 
in the 
next 
section 
on 


communication. 


Communication. 
The 
most 
common 
interaction 


between 
tasks 
is that 
of communication 
- 
the 
transmission 
of 
data 
from 
one 
task 
to 
another 


via an exchange 
(Figure 
5). 


Rectangles 
designate 
tasks 
while 
circles 
represent 


exchanges. 
Arrows 
that 
are directed 
from 
tasks to 


exchanges 
indicate 
send 
operations. 
Wait 
opera- 


tions 
are shown by arrows directed 
from exchanges 
to tasks. 


Figure 
5 shows 
an 
example 
of 
communication 


between 
task A and task B. Task A sends a message 
to exchange 
X and 
task 
B waits 
for a message 
at 
that 
exchange. 
Task 
A is the 
message 
producer 


and task B the message consumer. 


Synchronization. 
At times 
there 
is a requirement 
to 
send 
a synchronizing 
signal 
from 
one 
task 
to 


another. 
This signal can take the form of a message 
that 
contains 
only 
header 
information, 
that 
is, 


LINK, LENGTH, 
and TypE. 


Let 
us 
consider 
the 
implementation 
of 
a task 


scheduler, 
used 
for the purposes 
of synchronizing 


another 
task 
that 
performs 
a particular 
function 


at periodic 
intervals. 
The relationship 
b.etween 
the 
tasks and exchanges 
is shown in Figure 6. 


Task 
A, the 
scheduler, 
performs 
a timed 
wait on 


the 
X exchange. 
Note 
that 
the 
full 
wait 
period 


will 
always 
occur 
because 
there 
is no 
task 
that 


is sending 
messages 
to exchange 
X. In this manner, 


a specific 
timed 
wait by task A precedes 
the pass- 


ing of a synchronization 
message 
from 
task 
A to 


task 
B via exchange 
Y, and 
then 
the return 
from 


task B to task A via the Z exchange. 


If task 
B waited 
on X directly, 
rather 
than 
using 


task A for scheduling, 
it would be scheduled 
n sys- 
tem 
time 
units 
from 
when 
it waits 
instead 
of n 


units 
from 
the last time it was awakened. 
A com- 


parison 
between 
the 
two 
methods 
is shown 
in 


Figure 7. 


Mutual Exclusion. 
In an environment 
with multi- 


tasking, 
resources 
often 
must 
be shared. 
Examples 


of 
shared 
resources 
include 
data 
structures 
and 


peripherals 
such as the Intel SBC 310 Math Module. 


Mutual 
exclusion 
can be used to ensure 
that 
only 


one task has access to a shared 
resource 
at a time. 


Figure 
8 shows 
hO\; 
an exchange 
can be used to 


limit access to a resource. 


o 
.. 


In 
this 
example, 
the 
X exchange 
is sent 
a single 


message 
at system 
initialization. 
Then, 
as tasks re- 


quire 
the 
resource, 
they 
wait 
for a message 
from 


the 
X 
exchange. 
When 
the 
message 
is received, 
the 
task 
knows 
it has sole access 
to the resource 


because 
there 
is 
only 
one 
message 
associated 


with 
the 
exchange. 
After 
the 
task 
finishes 
with 


the 
resource 
it sends 
the message 
back 
to the 
X 


exchange. 
The 
next 
task 
waiting 
for the resource 
continues, 
knowing 
it has exclusive' 
access 
to the 


resource. 


EXTENSIONS 


RMX/80 
has 
several 
extensions 
which 
provide 


operations 
commonly 
used 
in 
real-time 
applica- 


tions. 
The 
nucleus 
of RMX/80 
requires 
less than 


two 
thousand 
bytes 
of memory 
and includes 
all 


of the 
basic 
operations. 
The 
extensions 
include 
a 


Free 
Space 
Manager, 
Terminal 
Handler, 
Disk File 


System, 
and a Debugger. 


FREE 
SPACE MANAGER 


The 
Free 
Space 
Manager 
maintains 
a pool 
of free 


RAM and 
allocates 
memory 
from 
that 
pool upon 


request 
from 
a task. The Free 
Space Manager 
also 


reclaims 
memory 
and 
returns 
it to the pool 
when 


it is no longer needed. 


The Free 
Space Manager 
is especially 
useful in two 


applications. 
The 
first 
application 
arises 
from the 


need 
for 
variable 
length 
messages. 
If you 
have 
a 


task 
that 
produces 
messages 
of 
variable 
length, 
such 
as a task sending 
text 
for display 
on a CRT, 
the 
Free 
Space 
Manager 
can 
be used 
to provide 


a message 
to meet 
your 
exact 
size requirements. 


An 
alternate 
solution 
is 
to 
maintain 
a 
pool 
of large 
fixed 
length 
messages. 
The 
pool 
can be 


maintained 
without 
the 
Free 
Space 
Manager; 


however, 
memory 
is wasted 
because 
of the unused 


space 
remaining 
in 
the 
fixed 
length 
messages. 


The second 
application 
of the Free Space Manager 


relates 
specifically 
to 
effective 
use 
of memory. 


In 
a typical 
application, 
the 
total 
RAM require- 


ment 
is computed 
by 
adding 
up 
the 
maximum 


RAM 
requirements 
for 
each 
task 
in a system 
as 


shown in Figl1re 9. 


} 
MAXe 


The efficiency 
of memory' 
utilization 
is a function 


of the 
total 
RAM memory 
needed 
during 
typical 


system 
operation. 
Reducing 
the 
total 
amount 
of 


RAM 
by 
sharing 
it 
among 
the 
tasks 
often 
has 


little 
impact 
on tota~ perforinance. 
However, 
signi- 
ficant 
cost' advantages 
may be gained 
by reducing 


the total 
amount 
of memory. 
The memory 
require- 


ments 
can be calculated 
as the minimum 
RAM for 


each task plus the pool (shared 
memory), 
as shown 


in Figure 
10. 
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TERMINAL 
HANDLER 


The 
Terminal 
Handler 
provides 
real-time 
asyn- 


chronous 
I/O 
between 
an operator 
terminal 
and 


tasks 
running 
under 
the 
RMX/80 
executive. 
The 


Terminal 
Handler 
provides 
a line-edit 
capability 


similar 
to that 
of ISIS-II 
and 
an additional 
type- 


ahead 
feature. 
(ISIS-II 
is the 
diskette 
,.supervisor 


system 
used on the Intellec 
Microcomputer 
Devel- 


opment 
System.) 
Acc~ss to the Terminal 
Handler 


is provided 
by two 
exchanges 
where 
messages 
are 


sent to in'itiate read and write requests. 


Several 
features 
of 
the 
Terminal 
Handler 
have 


been incorporated 
specifically 
to facilitate 
interac- 


tion with 
the debugger. 
Because of this interaction, 


the 
Terminal 
Handler 
is required 
for. operation 
of 


the debugger. 


DISK FILE SYSTEM 


The 
Disk 
File 
System 
(DFS) 
provides 
users 
of 


RMX/80 
with 
disk 
file management 
capabilities. 
This system 
allows user tasks to create, 
access, and 


maintain 
disk files in a real-time 
environment. 
This 


means 
that 
many 
I/O 
requests 
can be processed 


concurrently, 
rather 
than one at a time. 


In addition 
to the file handling 
services, 
DFS pro- 


vides a program 
loading 
facility 
that 
allows you to 


load 
program 
segments 
into 
memory 
from 
disk. 


The 
DFS 
can be configured 
to include 
only those 


functions 
which 
you 
require. 
For 
example, 
if 


your 
disk 
accesses 
are 
sequential 
rather 
than 


random, 
you omit 
the SEEK function. 
This philo- 


sophy 
of 
minimizing. 
memory 
requirements 
by 
including 
only 
the 
functions 
your 
application 
re- 


qaires 
is found 
in virtually 
all aspects 
of RMX/80. 


An 
environment 
that 
is continually 
changing 
in 


response 
to asynchronous 
physical 
events 
can pre- 


sent 
a serious 
debugging 
challenge. 
The Debugger 


aids 
you 
in 
debugging 
tasks 
running 
under 
the 


RMX/80 
executive.' 
The 
Debugger 
provides 
a 


command 
language 
that 
can b~ used 
to passively 


display 
information 
about 
the 
system, 
or, actively 


modify 
and interact 
with the system. 


Passive Functions' 


Because 
RMX/80 
manages 
a fairly 
complex 
set of 


data 
structures, 
the 
Debugger 
has 
the 
capability 


of 
displaying 
them 
in an intelligible 
format. 
The 


Debugger 
can 
be 
used 
in 
this 
manner 
to 
view 


tasks, 
exchanges, 
messages, 
and 
other 
data 
struc- 


tures 
maintained 
within 
the RMX/80 
environment. 


The 
contents 
of all' RAM and ROM memory 
loca- 


tions may also be displayed 
by the Debugger. 


Active Functions 


The 
active 
Debugger 
functions 
include 
those 
of 


modifying 
memory, 
setting 
breakpoints, 
and moni- 


toring 
stack 
overflow. 
The 
memory 
modification 


commands 
enable 
you 
to update 
the contents 
of 


memory- 
and 
to move 
a series 
of bytes 
from 
any 


location 
to any other 
location. 


Breakpoints 
can be set, allowing 
you 
to gain con- 


trol 
when 
encountered 
by 
a task. 
Two 
kinds 
of 


breakpoints 
are supported: 
execution 
breakpoints 


and 
exchange 
breakpoints. 
An 
execution 
break- 


point 
can be placed 
at any instruction 
within 
read/ 


write 
(RAM) 
memory. 
When 
the 
breakpoint 
is 


reached, 
the 
task 
encountering 
the breakpoint 
is 


stopped 
from 
further 
execution. 
The task registers 


may then 
be examined 
and modified 
before 
resum- 


ing execution. 


Exchange 
breakpoints 
can 
be 
used 
to 
detect 
RQSEND 
and/or 
RQWAIT 
operations 
performed 


on specified 
exchanges. 
The 
exchange 
breakpoint 
can thus enable 
you 
to monitor 
the activity 
of any 


of the exchanges 
in your 
system. 
The task execut- 


ing the 
appropriate 
RQSEND 
or RQWAIT 
to an 


exchange 
which 
has a breakpoint 
is stopped, 
allow- 
ing you 
to examine 
the task. This enables 
you 
to 


breakpoint 
a ROM resident 
task. The breakpointed 


task 
and 
the 
message 
involved 
in the 
operation 
with 
the 
exchange 
may 
then 
be 
displayed 
and 


modified 
before 
resuming 
execution. 


The 
deb'ugger 
can also be used 
to monitor 
stack 


overflow. 
This 
function 
is provided 
by 
the 
De- 
bugger 
SCAN command 
which examines 
the stacks 


of all tasks 
in the 
system 
at a specified 
periodic 


interval. 
The fact that each task's 
stack is initialized 


with, a unique 
value 
allows 
stack 
overflow 
to be 


detected. 
When 
a task 
stack 
overflows, 
it is re- 
moved 
from 
the system 
and a message is displayed. 


USING RMX/80 


This 
section 
of the 
application 
note 
describes 
the 


steps 
involved 
in 
using 
RMX/80. 
The 
process 


begins 
with 
the 
definitIon 
of the individual 
tasks 


and 
exchanges 
in your 
application. 
It 
continues 


with 
a discussion 
of the 
data 
structures 
that 
you 


must 
prepare. 
The 
task 
coding, 
compilation 
or 


assembly, 
linking, 
and 
locatirtg 
is also described. 


Finally, some comments are directed towards de- 
bugging tasks 
within 
the 
RMX/80 envirnment. 


Before the details of using RMX/80 are discussed, 
some general observations are necessary to deter- 
mine the suitability of RMX/80 for your applica- 
tion. To effectively utilize RMX/80, your applica- 
tion must either use interrupts 
or require device 


polling. Thus, the key element 
is the need to 


respond 
to external 
events. If your application 


satisfies this criteria, it is a likely candidate. How- 
ever, you must then determine if RMX/80 is capa- 
ble of supporting 
your application. 
This can be 


done by examining your interrupt 
response time 


and frequency requirements. The time required to 
transform an interrupt 
into a message that is sent 


to an interrupt 
exchange is approximately 
800 


microseconds 
for 
an 
SBC 80/20. 
This is the 


RMX/80 interrupt 
latency. 
It can be reduced to 


60 microseconds by handling the interrupt directly, 
using 
the 
RQSETV 
operation 
to 
bypass 
the 


RMX/80 interrupt 
exchange mechanism. In this 


latter 
mode, 
an 
interrupt-driven 
asynchronous 


block transfer rate of about 10kHz can be achieved. 


TASK AND EXCHANGE DEFINITION 


The initial design step for an application that runs 
under 
the RMX/80 Executive is to define your 


tasks, 
exchanges, 
and 
the 
interaction 
between 


them. This is perhaps best accomplished using the 
graphic notation 
introduced 
earlier in the section 


on Send - Wait Interaction. 
The graphic notation 


provides a clear picture of the relationships 
be- 


tween 
the tasks and exchanges in your system. 
You can begin either in a top-down or bottom-up 
fashion. That is, you can use a top-down approach 
to define, at a gross level the operation of your 
system and then gradually break it down to the 
individual tasks. Or, you can start with the tasks 
associated with the external events in your appli- 
cation and then build the pieces to form the gross 
structure of your system. 
The bottom-up 
approach forces you to begin with 


external events that drive your system. The num- 
ber 
of these events, the 
amount 
of processing 


required, 
and 
the 
relationships 
between 
them 


define the tasks and exchanges in a system. For 
example, consider a system that samples an analog 
input with an A/D converter. Assume that the A/D 
provides an interrupt 
at the completion of a con- 


version. To use the data from the A/D converter it 
may also be necessary to scale it and add an offset. 


With this information the portion of the task and 
exchange definition 
that relates to this function 


can be constructed. 
Begin with the external ,event, the interrupt 
from 


the A/D. An "interrupt priority level must be as- 
signed to the AID 
converter. This same level will 


be used by the task which waits on the interrupt 
exchange. 


The relationship 
between 
the interrupt 
exchange 


and the A/D task is shown in Figure 11. If pro- 
cessing must be performed on raw data from the 
A/Dl a second, lower priority, task could be used. 
Another task for this function will require a syn- 
chronizing signal from the ADC task to indicate 
that raw A/D data has been obtained and is ready 
for processing. 
00 


The interaction 
between the ADC task and the 


CONY task that processes the raw A/D data is 
shown 
in 
Figure 
12. 
Two 
exchanges 
provide 


synchronization. 
The ADC task uses the TRGR 


exchange to signal that data is ready for process- 
ing by the CONY task. The CONY task uses the 
RTRGR exchange to signal the completion of its 
processing and thus its readiness to accept more 
raw data. 


In 
this 
example 
two 
tasks 
and 
three 
exchanges 


have been 
defined. 
To develop 
an entire 
system, 
the tasks and exchanges 
associated 
with all of the 


external 
events 
in the 
system 
can be defined 
in 
the 
same 
manner. 
Then, 
proceeding 
bottom-up, 
the next step is to defme the tasks and exchanges 
required 
to support 
the interaction 
between 
tasks 
running at the level of the real-time events. 


After defining the entire application, 
you can begin 


actual 
coding 
of the 
tasks. 
You 
may 
choose 
to 


code in either 
assembly 
language 
or the PL/M 80 


high-level language. 
Where possible, 
it is desirable 
to 
code 
in PL/M 
because 
PL/M 
lends 
itself 
to 


structured 
programming. 
Assembly 
language often 


encourages 
an ad hoc approach. 
Even if your appli- 


cation ultimately 
requires assembly language coding 
because 
of critical 
time and/or 
space parameters, 


initial 
design 
work 
in PL/M followed 
by transla- 
tion 
into 
assembly 
language 
is 
recommended. 


A total 
of 
IS operations 
are supported 
by the 


RMX/80 
nucleus. 
Only 
two 
of 
the 
operations, 


RQSEND and RQWAIT, are described in any detail 
in this application 
note. The remaining 
operations 


are described 
in the RMX/80 
User's Guide. 
The 


reason for presenting 
only the send and wait opera- 
tions 
is because 
they 
are sufficient 
for the imple- 


mentation 
of a large number 
of real-time 
applica- 
tions. These two operations 
provide a great deal of 


power 
and flexibility, 
yet their 
simplicity 
should 


enable 
those 
who 
are new to real-time 
program- 
ming to quickly develop applications. 


The relative priority 
of tasks within 
a system run- 
ning under 
RMX/80 
determines 
which 
task is to 


be executed. 
Therefore, 
the assignment 
of a pri- 
ority 
to each task is extremely 
crucial. For exam- 


ple, 
consider 
a compute 
bound 
task placed 
at a 
higher 
priority 
than 
an 
interrupt-driven. 
task 
responsible 
for servicing 
an I/O 
device. This im- 


proper 
assignment 
of 
priorities 
could 
result 
in 


missed 
interrupts 
from 
the 
I/O 
device. 
Several 


steps 
can be followed 
in the assignment 
of task 
priorities. 


I. Assign 
hardware 
interrupt 
priority 
levels 


according 
to the requirements 
of your appli- 


cation. 


2. Specify 
priorities 
for the tasks which service 


the 
interrupts. 
These 
tasks 
should 
generally 


be short 
and serve only to perform 
the data 


transfers. 
A second task with a priority 
lower 


than 
those 
assigned 
to the 
hardware 
inter- 


rupts should be used where further 
processing 


of the data is required. 


3. Priority 
assignment 
should 
be made 
for all 


other tasks in the system based on the relative 
importance 
and interaction 
among the tasks. 


Unfortunately 
the 
last 
step in assigning task pri- 


orities 
is largely intuitive. 
In fact, you 
may need 


some 
empirical 
data 
from 
actually 
running 
your 
application 
before 
you 
settle 
on your 
fmal task 


priority 
assignment. 


STATIC DESCRIPTORS 


When 
a 
system 
running 
under 
RMX/80 
begins 


execution, 
several 
tables 
of data 
are used to ini- 


tialize 
the 
system. 
These 
tables 
usually 
reside in 


ROM. The first table is the create table (RQCRTB) 
that 
specifies 
the number 
of tasks and exchanges 


in 
the 
system, 
and 
the 
addresses 
of the 
initial 


task table 
and the initial 
exchange 
table. The ini- 
tial exchange 
table 
contains 
the 
addresses 
of all 


the 
exchange 
descriptors. 
The 
initial 
task 
table 
contains 
the static 
task descriptors 
for each task, 
and contains 
the following task parameters. 


I. Name 


2. Initial 
PC - 
the 
location 
at which 
to start 


task execution 


3. Initial 
SP - 
the 
location 
at which 
to start 


the task stack 


4..Stack length 


5. Priority 


6. Initial 
Exchange 
(described 
in the RMX/80 


User's Guide) 


7. TD Address 
- 
the RAM address 
of the task 


descriptor 


You must prepare 
all three of these tables to pro- 


duce 
a configuration 
module 
for 
RMX/80. 
The 


release diskette 
for RMX/80 
includes 
a set of files 
which contain 
assembly language macros that sim- 
plify the preparation 
of your configuration 
module. 
The relationship 
between 
these tables is shown in 


Figure 13. 


Preparing 
program 
segments 
for compilation 
and 


assembly 
can be simplified 
by use of files provided 


on the RMX/80 
diskette. 
As described 
in the last 


section, 
a set of macros 
is included 
to assist you in 


preparing 
your 
configuration 
module. 
Other 
files 
are provided 
that 
are useful 
when 
coding 
calls to 


RMX/80 
and 
preparing 
data 
structures 
in PL/M. 


By coding 
in a modular 
fashion 
you can separately 


compile 
and maintain 
tasks. 
This is advisable 
since 


a single 
large 
module 
containing 
all your 
tasks 


would 
require 
a lengthy 
recompilation 
to change 
anyone 
of the 
tasks. 
Following 
the 
compilation 


and 
assembly 
of 
your 
source 
code 
modules, 
a 
library 
containing 
the 
object 
modules 
can 
be 
created. 


The process 
of linking 
prepares 
a single object 
mo- 


dule 
from 
libraries 
containing 
the RMX/80 
object 


modules 
and 
your 
own application 
libraries 
or se- 


parate 
object 
modules. 
The 
order 
in which 
you 


specify 
the files to be linked is crucial to successful 


linking. 
In general, 
your libraries 
or separate 
object 


modules 
should 
be specified 
before 
the 
RMX/80 


libraries. 
The link command 
should 
conclude 
with 


the 
unresolved 
library 
(UNRSLV.LIB) 
that 
con- 


tains miscellaneous 
modules 
for resolving 
PUBLICs 
not used in the application 
code. 
PUBLICs extend 


the 
scope 
of variables 
to 
allow 
linkage 
between 


separate 
program 
modules. 
Figure 
14 illustrates 


how an application 
program 
is linked from RMX/80 


and user tasks. 


It is appropriate 
in this section 
to give some guide- 


lines 
regarding 
the 
assignment 
of RAM and ROM 


address 
space 
for 
your 
Single 
Board 
Computer 
environment. 
The SBC 80 Single Board Computers 
have ROM based 
at location 
O. Since the LOCATE 
program 
places 
all code in a contiguous 
block, 
the 
code must 
begin at location 
O. Likewise, 
the read/ 
write 
(RAM) 
data 
is also placed 
in a contiguous 


block. 
The 
base 
address 
of data 
should 
be placed 


at 
your 
RAM 
base 
address. 
Depending 
on 
the 


amount 
of code 
space 
required 
by your 
applica- 


tion 
it may be necessary 
to move the RAM mem- 


ory base address 
on your SBC to a higher location. 


A STACKSIZE 
of zero should 
be specified 
because 


you 
allocate 
stack 
for each 
RMX/80 
task 
in the 


static task descriptors. 


DEBUGGING 


As mentioned 
in the overview 
of the RMX/80 
De- 


bugger, 
the 
real-time 
environment 
is a complex 


one 
in which 
to debug 
your 
programs. 
Intel 
pro- 


vides 
two 
tools 
that 
you 
can use for debugging. 


The 
RMX/80 
Debugger 
and 
the 
Intel 
In-Circuit 


Emulator 
(ICE). 
It is desirable 
to 
have 
both 
of 


these debugging 
tools at your disposal. 


ICE enables you to use Intel Microcomputer 
Devel- 


opment 
System 
memory 
in place of SBC 80 mem- 


ory. This allows RAM residency 
during your debug- 


ging as opposed 
to programming 
PROMs for each 


iteration. 
Your 
system 
may initially 
fail before 
the 


RMX/80 
Debugger 
can 
begin 
operation. 
In this 


situation 
ICE can be used to debug 
your program. 


APPLICATIONS 


RMX/80 
is suitable 
for a wide variety 
of applica- 
tions. 
Two 
specific 
examples 
are presented 
in this 
application 
note. 
Each 
example 
illustrates 
the 
steps 
involved 
in using 
RMX/80 
and 
provides 
a 


detailed 
description 
of the coding itself. 


MINIMAL 
TERMINAL 
HANDLER 


The basic functions 
required 
for a terminal 
handler 


are 
well 
defined. 
The 
handler 
must 
respond 
to 


operator 
input, 
transmit 
output 
characters, 
and 


echo 
characters 
as they 
are entered. 
This applica- 


tion note 
describes 
one implementation 
of a mini- 


mal terminal 
handler. 


The 
terminal 
handler 
presented 
here 
is not 
the 


RMX/80 
Terminal 
Handler. 
It does 
provide 
some 


common 
functions 
and 
uses 
the 
same 
exchanges 


and 
message 
formats. 
However, 
many 
features 


of the 
RMX/80 
Terminal 
Handler 
have been 
left 


out. 
Omitted 
features 
include 
special hooks 
to run 


with 
the 
Debugger, 
an alarm exchange, 
control 
S, 
Q, and 0 operations. 


As described 
in the chapter 
on using RMX/80, 
the 


process 
of developing 
an RMX/80 
application 
be- 


gins with the definition 
of the tasks and exchanges. 


The 
graphic 
notation 
is used to prepare 
a diagram 


(Figure 
IS) showing 
the tasks, exchanges, 
and their 


interaction. 


O 


Ol6EXRECEIVER 
~ADY 
••••• 
_ 


~ 
USART 
---- 


As 
shown 
in Figure 
15, the 
RDMIN 
task 
waits 


on the 
RQINPX 
exchange 
for input 
requests. 
The 


RDMIN task also successively 
waits on the RQL6EX 


and 
RQL7EX 
exchanges. 
It 
uses 
the 
RQL6EX 


exchange 
to determine 
when 
a character 
has been 


received 
by the 
USART. 
The 
RQL 7EX exchange 


is used 
to indicate 
when 
the 
transmitter 
is ready 


to accept 
another 
character. 
RDMIN uses RQL 7EX 


for echoing 
input 
characters. 


The WRMIN 
task waits on the RQOUTX 
exchange 


for output 
requests. 
When it receives 
a request, 
it 


waits 
on the RQL7EX 
to determine 
when 
charac- 


ters can be sent to the US ART. 


The 
following 
listing* 
shows 
the 
RDMIN 
and 


WRMIN 
tasks. 
These 
tasks 
provide 
a minimal 
ter- 


minal 
handler. 
The 
program 
is written 
in PL/M. 


The 
WRMIN 
task 
is also 
presented 
in assembly 


language 
in 
Appendix 
B. The 
program 
listing 
is 


interspersed 
with 
explanatory 
text. 
The 
program 


begins 
with 
the 
program 
segment 
label 
"MINI- 


MAL$TERMINAL$HANDLER:" 
and 
a DO state- 


ment. 


Several 
macros 
are 
declared 
using 
the 
reserved 


word 
LITERALLY. 
These 
macros 
are 
expanded 


at compile 
time by textual 
substitution. 


/. 
SP!::ClA!.. 
ASCII 
CHARACTERS 
'/ 
D£CLARE 
abU."" 
CONTliOL$k 
CQhTI\OL$X 
<SC 
RUBOUT 


LI'l'ERALLY 
'07H'. 
LITERALLY 
'BAH', 
LITERALLY 
'ilOH'. 
LI1'[RALLY 
'12H', 
LITERALLY 
'ISH'. 
LITlMLLY 
'ISH'. 
LITERALLY 
'7FIl'; 


Some 
macros 
are used to simplify 
the declaration 


of 
RMX/80 
data 
structures. 
The 
structures 
de- 
clared 
here 
are for the exchange 
descriptor, 
inter- 


rupt 
exchange 
descriptor, 
and 
the 
messages 
used 


by the minimal 
terminal 
handler. 


c.lCLARE 
tXCHANGE$DE&CkIP1'OR 
LITLRALLY 
'STRUCTURE 
I 


f'tESSAGE$hEAD 
AOl;kESS. 
ft.e.SSAGESTAIL 
AODRl:.&S, 


1ASk$HEAD 
ADOfil55. 


'lASK$TAIL 
ADDRESS. 
EXCHANGE$LINK 
ADDRESS)'; 


DE-CLAR/:. 
IN'$EXCHANGE$OESCRIPTOR 
LITERALLY 
'STkUC'WRE 
( 


MESSACE$Ill:.AO 
ADCRlSS, 
f'tLSSAGt$TAIL 
AD[jkESS. 


TASK$HEAD 
ADDRESS. 


TAS)I;$TAIL 
AODR£SS. 
tXChANGE$LU,k 
AOOl<1:;55, 
LINK 
ADDRESS, 


LENGTH 
ADDRESS, 


TYPE 
BYTE)'; 


DECLARE 
1hSMSG 
LITlRALLY 
'S1"RUCTURE{ 


Llf1lK 
ADDkf.Ss, 
LU.GTH 
AOCRf.SS, 


TYPE 
E'iTI:., 
nOf"lESEXCHAfIlGf.. 
AliCRt;SS, 


Rl::.1'OfIl"ESEXChAfIlGf.. 
A£leRl5s, 
S-rA1-US 
ADDJU.SS, 


BUfflRSA£lDii.f..SS 
Ac"L>Rf.SS. 


COU~1 
ADCRf.SS, 


AC111AL 
AC,DRlSS) 
, ; 


The 
following 
macros 
are specifically 
for the SBC 


80/20. 
The 
macros 
require 
changes 
to 
run 
the 


minimal 
terminal 
handler 
on 
a 
different 
Single 


Board 
Computer. 
Intel 
8253 
timer/counter 
and 


8251 USART 
chips are used. 


I" 
825] 
PORT 
ADDRESSES. 
"I 
t;t.CLARE 
A825l$HODE 
LITERALLY 
'IOFH'I 
DECLARE 
A,82SUCTf;.2 
LI'l'lRALL't: 
'IDEft', 


I" 
825) 
COflUlA-NOS. 
"I 
DECLARE 
5£L£CT$2 
LITERALLY 
• UIUlin' 
I 


DECLARE 
flL$8OTH 
LITERALLY 
'''~18l''8' 
I 
DECLARE 
1400£$] 
LITERALLY 
• ••••• 
UI8': 
DECLARE82411 
LITt:RALLY '11lCIl', 


I" 


8251 
PORT AQORESSES, 
"I 
DECLARE 
USART$lN 
LITERALLY 
• ItCll' 
• 
USART$OUT 
LITBRALLY 
'itCh'. 
USART$CONTROL 
LITERALLY 
• ItOh' 
1 


I" 
8251 
MODES. 
"I 
DECLARESTOPSl 
LITERALLY'111"8118': 
DECLARE 
CL8 
LITERALLY 
' ••• 
UlIlS', 
. 


DECLARE 
RAT£$16X 
LITERALLY 
• •••• 
8111B·, 


I" 
8251 
COMMANDS. 


"I 
DECLARE 
USART$R£S£T 
LITERALLY 
"lI"U.S'. 
aTS 
LITERALLY 
'881ell881B', 


ERROR$RESET 
LITERALLY 
'UlU.Ula', 


aXE 
LITERALLY 
'1I1II8U88', 


OTR 
LITERALLY 
'UIIUB18B'. 


TXEN 
LITERALLY 
'8i118il8lJ1S'l 


RDMIN and WRMIN call three RMX/80 opera- 
tions. They are RQSEND, RQWAIT, and RQELVL. 
RQSEND and RQWAIT allow tasks to send and 
receive messages from exchanges. RQELVL enables 
a specific interru pt level. 


Rf,jSENO: 


pROCEDt/rtt. 
t EXCHANGES 
pOII\ITER, 
MESSAGESpOI 
NTER) 
EXTERNAL, 
DECLARE 
tEXCHAHGE$pOINTER,MESSAGf:$pOINTER) 
ADDRESS, 


END 
RUSU"D; 


R';ll<lAl'1: 


PROCEDURE 
(EXCHAHGE$POII\ITER,DELAY) 
ADDRESS 
EXTERNAL, 


DECLAflE 
(EXCHANGt.$POIH1ER,DELAY) 
ACDRESS; 
£I\ID 
flu""AIT, 


25 
Rl.IELVL: 


pROCEOUJiE 
(LEVELl 
£XTERNAL; 
26 
C£CLARE 
LEVt,L 
BYTE; 
27 
END 
Rvl.LVL: 


The exchange descriptors and interrupt 
exchange 
descriptors 
must 
be 
PUBLIC ·because they 
are 
referenced by the configuration module. 


28 
CECLARE 
ii.\JIHPX 
£ll.CHAHGE$OtSCRII'TOR 
PUBLIC; 


29 
DECLARE 
RvQUTX 
EXCHAHGESDESCRIPTOR 
PUBLIC; 


31 
DECLARE 
ROL6EX 
U"T$EXCHAHGE$DESCRIPTOR 
PU8LIC; 
U 
DECLARE 
R~L7tX 
IHT$EXC"ANGE$DESCRIPTOR 
PUBLIC; 


The following procedure initializes the 8253 and 
8251 (USART). The 8253 generates the baud rate 
clock (2400 baud in this example). The program 
sends four nulls to the USART control port to 
ensure that the USART is ready for a command, 
no matter what state it was previously in. The pro- 
gram then sends a reset command to the USART, 
followed 
by 
the mode 
and another 
command. 


II\IITIALIZATIOH: 
PkOCECURE; 
OUTpUT(A825)$/IIOO£) 
• 
S2LECT$2 
OR 
~L$BOTH 
OR 
MODtH, 
OUTPUTIA825l$CTR2) 
• 
LOM(e2UI) 
I 
W 


OUTPU'l'IA825l$CTRl) 
• 
HIGH 
(B24IlI), 
OUTPUTIUSAkT$COtn'ROLI, 
OUTPUT 
IUSART$COHTROLI 
, 
OUTPUT 
(USART$CONTROL) 
, 
OUTpUTIUSARTSCONTROLI 
• 
I, 
OUTpUTIt/SART$COl'oTROL) 
• 
USART$RESET; 


OUTPUl'(USART$eOHTROL) 
• 
STOP$! 
OR 
eL8 
OR 
RAT£$!6X; 
OUTPUTIUSART$COhTACL) 
• 
RTS 
OR 
ERROR$RESET 
OR 
RXE 
OR 
OTR 
OR 
TXEN; 


Tasks coded in PL/M take the form of parameter- 
less PUBLIC procedures. 
The procedure 
declara- 
tion is followed by the variables used in ~DMIN. 
MSGPTR receives the address of an input request 
message. 
The 
based-variable 
MSG accesses the 


data in the input request message. INTMSG is a 
dummy variable which simply receives the address 
of the interrupt 
message. BUF$ADDRESS points 
to the buffer where the input characters are to be 
placed: 
The BUF array is based at the buffer 
pointed to by BUF$ADDRESS. 


RD$/IIIN: 
PROCEDURE 
PUBLIC: 
DECLARE 
IflSGPTa.. 
IHTflSC; 
,BUF$ADDRESS) 
AOORESS; 
DECLARE 
(CHAR,P1"k,I) 
BYTE; 
DECLARE 
fiSC; 
BASED 
foISGPTR 
TH$MSe; 
DECLARE 
(BUF 
SASLO 
BUFSAOORfoSS) 
(I) 
8YTE; 


The RDMIN task echoes characters after they are 
read in. The ECHO$CHAR procedure performs this 
function. It waits for a level 7 interrupt, indicating 
that the transmitter is ready for another character. 
ECHO$CHAR then transmits the character. 


f:.CHO$ClIAI'.: 


PROCEOUflf:. 
(ChAR): 
DECLARE 
CHAR 
BYTE.; 
INTMSG 
• 
ROl<lAI1I.RC/L7EX,I): 


OU1'PU1lUSARl 
$OU1") 
• 
ClIAR; 
END 
ECHO$C"AR: 


Execution of the RDMIN task starts with the next 
statement, 
a call to the initialization 
procedure. 


This call is followed by two calls to the procedure 
which will enable interrupt levels 6 and 7. 


The basic structure of an RMX/80 task is that of 
a program with an imbedded 
infinite loop. This 


loop starts with 
the 
DO FOREVER 
statement. 


In the continuous loop, the task waits for an input 
request message. This wait is satisfied when some 
other task in the system sends an input request 
messag~ to 
the 
RQINPX 
exchange. 
The based 
variable used to point to BUF is assigned from a 
field in the 
input 
request 
message, MSG.BUF- 
FER$ADDRESS. 
An index 
for the BUF array, 


PTR, 
and 
the 
variable 
CHAR 
are 
initialized. 


00 
f'OREVf:.R; 
/IISePTR 
• 
ROl<lAIT(.ROINPX,I); 
BUF$AODRE.SS 
• 
foIse.8urf'ERSAOORESS 
- 
1, 


PIR 
• 
I; 
ellAR 
• 
/'100'1 CR; 


Task 
execution 
continues 
inside the next 
loop 


until a. carriage return 
(CR) is input. An escape 


character 
(ESC) within the loop simulates a CR 


which 
enables 
an exit 
from 
the 
loop. 
The 
task 


simply waits on the RQL6EX 
exchange 
for a mes- 


sage. This amounts 
to an interrupt 
service routine. 


When the wait is satisfied, the USART has received 
a character. 


The 
next 
statement 
performs 
a whole 
series of 


operations. 
The character 
input 
from the USART 


is logically ANDed with 7FH to mask off the parity 
bit, assigned to the variable CHAR, and tested 
to 


determine 
if it is a RUB OUT character. 
If a RUB- 


OUT is found, 
either a BELL is echoed 
to the ter- 


minal if there 
are not characters 
to delete 
in the 


buffer 
(PTR 
= 0), 
or 
the 
last 
character 
in the 


buffer 
is echoed 
and the pointer 
is decremented. 


If 
(CHAR 
:. 
INPUT(USAR1SINJ 
AND 
7fHl 
•• 
RUDOllT 
THEN 


00; 


IF 
1'1'11: •• 
0 
ThEN 
CALL 
ECI10$CHARIBELL1; 


ELSE. 
00, 
CALL 
ECIiGSCHAR(BUftPTRj,; 


P'IR 
••. PTR 
- 
1; 


END; 
END; 


If CHAR 
is not 
a RUBOUT, 
it is tested 
for a 
CONTROUX. 
The 
function 
of a CONTROUX 
is to 
delete 
the 
entire 
line by resetting 
PTR to 
zero. After 
deleting 
the line, the system prompts 
the operator 
with a "#" character 
and is ready to 


accept a new line. 


.lLSE 
00, 
IF 
CHAR'" 
CONTROL$X 
ThEN 
00, 
CALL 
ECHO$CHAR 
( • t· J ; 
CALL 
ECHO$CHARtCRJ; 
CALL 
ECHOSCHAR{Lfl; 
PTR 
•• 
B; 


EHO; 


The 
next 
test 
determines 
if CHAR 
is a CON- 


TROUR. 
CONTROL$R 
echoes 
the 
entire 
line 
that 
has been entered. 
This function 
is useful for 


displaying a line containing 
a number of RUBOUTs. 


Such 
lines 
can be difficult 
to interpret 
because 


RUBOUT 
echoes 
deleted 
characters. 
Because 


CONTROL$R 
echoes 
only 
the 
remaining 
data 


in 
the 
buffer, 
it eliminates 
"garbage" 
from 
the 
display. 


ELSE 
00, 


If' 
C"Ak 
•• 
CVf'oTkOL$k 
ThEN 
DO; 
• 
CALL 
E(HOSCh"kj'''); 
CALL 
ECitOSChARjLf'): 


DO 
1 
" 
1 
1'0 
1'11,; 


CALL 
ECkCSChAklBUFII)); 


ENLI; 
!:.Nl); 


The character 
is then 
placed 
in the buffer 
unless 


the 
end 
of the 
buffer 
has been 
reached. 
If the 


buffer 
is full, 
a BELL 
is sent 
to 
the 
terminal. 


ELSE 
00, 
If 
1'1'1< 
( 
MSG.COlil'<1 
'fhtN 


BUf(PTR 
:'" 
1'1"+1) 
•• CHAR; 
ELSE 
00; 


If 
ChAR 
<> 
Ck 
'l'HL/,; 
CHAR" 
BlLL; 
I:.NC; 


The last test is for an ESC character. 
It is echoed as 


a "$" 
and 
is treated 
as if a CR were 
entered. 


If 
CnAiI. 
•• 
I:.::,C 'lhE.1\; 
00, 


CALL 
EChOSCHAh 
( • S' 
I ; 
ChAR" 
CR; 
troD; 
CALL 
E.CHO$ChAf< 
(CHA"I 
; 
END; 


ENe; 
lND; 
toNO; 


The program 
places a line feed (LF) at the end of 


the buffer 
when an exit is forced 
by a CR or an 


ESC. The 
input 
request 
message actual 
character 
count 
(MSG.ACTUAL) 
and 
the 
status 
(MSG. 


STATUS) 
are set before 
sending 
the message to 
its response exchange. 


If 
PTR 
( 
I'ISG.COU/'oT 
ThEN 
BUf(PTR'*'fo1k+l1 
" 
Lf; 


MSG ••••CTU •••L 
• 
PTR; 


MSG.S'l"'TUS 
• 
II; 


C"'LL 
RI./SlNO 
(MSG. 
RESPONSE$EXCn"'t-GE,MSGP'l'R) 
; 
C"'LL 
ECI1t1$Ch 
•••R{Lfl: 
I:.ND; 


END 
r.C$MIN; 


The 
WRMIN 
task 
begins 
by 
enabling 
interrupt 


level 7. Note 
that 
no other 
initialization 
is per- 
formed 
before WRMIN waits for an output 
request 


message to arrive at the RQOUTX 
exchange. 
Here 
correct 
operation 
depends on the fact that RDMIN 


has a higher 
priority 
than WRMIN. Were this not 


the case, WRMIN could try to transmit 
a message 


before 
the 
8253 
and 
8251 
have 
been 
set 
up. 


112 
1 
,,"K$MIN: 


PROCEOURl 
PUBLIC; 
113 
DE-CL"'RE 
(foISGPTR,IN1MSG,IHJf$"'DIJRl:>S) 
ADDRESS, 
114 
DECLARE 
PTR 
BYTl, 
11S 
DECLAI<E 
I1SG 
BASE.D 
MSGP'rR 
TH$MSG: 


116 
DECLARE 
(BUF 
B"'SED 
BUf$ADDRlSSJ 
(1) 
BYTE; 


117 
2 
CALL 
RI./ELVL 
(7) 
, 


118 
DO 
fvREV£R; 
119 
MSGPTR 
• 
ROIolAI1{.ROOU1'X,01; 


128 
BUfS 
•••OORESS 
*' 
MSG.BUffE.R$ 
•••DORlSS 
- 
1; 


The next loop transmits 
all of the characters 
speci- 


fied by 
the 
output 
request 
message. Once again, 


the 
interrupt 
service 
routine 
is implemented 
by 
simply 
waiting 
on the 
RQL 7EX 
exchange 
for a 


transmitter 
ready 
interrupt 
message. 
When 
this 


message 
is 
received, 
the 
next 
character 
in 
the 


buffer is transmitted. 


00 
PTR 
• 
1 
TO 
KSG.COUNT: 
INTKSG 
• 
RO .•••\IT(.RQL7EX.IIJ; 
OUTPUT(USART$OUT) 
• 
BUf(PTR); 


ENOl 


The WRMIN task concludes 
by setting the actual 


count 
and 
status, 
and 
then 
sends the output 
re- 


quest message to its response exchange. 


125 
/IISG.ACTUAL 
• 
KSG.COUNT; 
126 
MSG.S1'ATuS 
• 
II; 
127 
CALL 
RQSl,ND 
(MSG. 
RESPONSl.$EXChANGE. 
KSGPTRj 
: 
128 
END; 
129 
END ~R$MIN: 


Using the 
macros 
provided 
on the 
RMX/80 
dis- 


kette, 
the following 
static 
task descriptors 
(STD) 


should 
be placed 
in your 
configuration 
module. 


STD 
RDMIN,64,112,0 


STD 
WRMIN,64,128,0 


the symbolic name assignedto the task asso- 
ciated with the STD 


the number of 
bytes allocated to the task 
stack 


the task priority level 


an optional field, usually 0 


PRI 


EXCH 


Priorities 
of 
112 and 
128 have been assigned to 
RDMIN and WRMIN because 
they 
correspond 
to 


hardware interrupt 
levels 6 and 7. 


The 
following 
exchange 
addresses 
should 
be 


placed in your configuration 
module. 


XCHADR 


XCHADR 


XCHADR 


RQINPX 


RQOUTX 


RQL6EX 


XCHADR 
RQL7EX 


The XCHADR macro only requires 
the address of 


the exchange descriptor. 


Characters 
typed 
at the terminal 
are ignored unless 


an input 
request 
message has been received. Thus, 


type-ahead 
is 
not 
a 
built-in 
feature. 
However, 
if type-ahead 
is desired, 
it is sufficient 
to ensure 


that 
input 
requests 
are 
always 
queued 
for 
the 


RDMIN 
task 
and 
that 
the 
full input 
buffers 
are 
sent 
to 
an 
exchange 
that 
queues 
full 
buffers. 


This can easily be accomplished 
by sending several 


input 
requests 
to 
the 
RQINPX. 
These 
input 


requests 
have 
the 
address 
of a "full-buffer" 
ex- 


change 
as the response exchange and the RQINPX 


exchange 
as the home exchange. 
Then, tasks need- 


ing terminal 
input 
wait 
on 
the 
"full-buffer" 
ex- 
change and send the message to the home exchange 
when finished. 


In the next example, 
a closed-loop 
analog control 


subsystem 
using 
the 
Intel 
SBC 
711 
analog-to- 
digital 
board 
illustrates 
task 
scheduling 
and syn- 


chronization 
in a process 
control 
application. 
In 


general, 
the subsystem 
samples an analog input 
at 


specified intervals, converts the data to temperature 
in degrees centigrade, 
and then - 
based upon pro- 


grammed 
temperature 
limits - 
controls 
a heating 


element. 
The algorithm 
used provides 
a 2-position 
controller 
with neutral 
intermediate 
zone (or sim- 


ply 
"bang-bang" 
control). 
The control 
algorithm 


is shown in Figure 16. 


POSITION,OUTblLPUT 
~SWITCHING 
POINTS 


(ON) 
\: 


I 
I 
I 
'- 
Prn:~T~~)N 2 
TEMPERATURE 


SETPOINT 


Figure 16. 2·Position Controller with Neutral Intermediate 


Zone 


The 
graphic 
notation 
in Figure 
17 diagrams 
the 


tasks, exchanges, and their interaction. 


This 
application 
includes 
three 
tasks and six asso- 


ciated 
exchanges. 
The 
TICKER 
task 
schedules 
the 
ADC 
task. 
TICKER 
has a very high 
priority 
because 
nothing 
else 
in the 
system 
should 
inter- 


fere 
with 
its scheduling 
activities. 
It is also a very 


short 
task 
since 
it repetitively 
executes 
a timed 
wait and then handshakes 
a message. 


TICKER 
schedules 
the 
ADC task. 
The 
ADC task 


services 
the 
A/D 
converter. 
After 
obtaining 
data 


from 
the 
A/D 
it handshakes 
with 
the CONTROL 
task 
to 
signal 
that 
data 
is ready 
for 
processing. 
The 
ADC 
task 
is 
assigned 
a priority 
equivalent 


to 
the 
level 
of 
the 
hardware 
interrupt 
from 
the 


A/D. 
Clearly, 
calculations 
should 
not be performed 


at that priority. 


Thus, 
CONTROL 
performs 
the processing 
function 


at a lower 
priority. 
The CONTROL 
task used the 
T$P ARAM$LOCK 
exchange 
to 
govern 
access 
to 


the 
control 
parameters. 
This 
avoids 
problems 
re- 


sulting 
when 
some 
other 
task 
is updating 
the pa- 


rameters 
at the 
same 
time 
the 
CONTROL 
task is 


using them for testing. 


As in the minimal 
terminal 
handler, 
the following 


listing 
contains 
the 
complete 
analog 
subsystem 
tasks 
and 
is interspersed 
with 
explanatory 
text. 


The 
program 
begins 
with 
the 
program 
segment 


label "ATOD:" 
and a DO statement. 


The 
macros 
and 
externals 
used 
in 
this 
module 


are brought 
in by means 
of INCLUDEs 
from 
the 
RMX/80 
diskette. 


$INCLlJDE(:Fl:COMHON.ELT) 
DECLARE 
TRUE 
LITERAl.LI 
• OFFH' 
; 


DECLARE 
FALSE. 
LITERALLY 
• OOH'; 


DECLARE 
BOOLEAN 
LITERALLY' 
BYTE'; 


DECLARE 
FOREVER 
LITERALLY 
'WHILE 
l' 


$lNCLUDE( 
: 1'1: 
EXCH. 
ELI) 
DECLARE 
EXCHANCESDESCRIPTOA 
LITERALLY' 
STRUCTURE: 
( 
HE:SSAGE$HEAD 
ADDRESS, 
MESSAGESHIL 
ADDRESS, 


tASK$HEAD 
ADDRESS, 
TASK$TAIL 
ADDRESS, 


EXCHANGEHINK 
ADDRESS)'; 


SlNCLUDE( 
:,1 
: lED. 
ELI) 


DECLARE 
INT$EXCHANGE$DESCRIPTOR 
LITERALLY' 
STRUCtURE 
( 
HESSAGE$HEAD 
ADDRESS, 
HESSAGE$TAlL 
ADDRESS, 
TASK$HEAD 
ADDRESS, 


tASKHAIL 
ADDRESS, 


EXCHANGE$LINK 
ADDRESS, 


LINK 
ADDRESS, 


LENGTH 
ADDRESS, 


TYPE 
8YTE)'; 


$INCLUDE(:Fl:HSG.ELT) 
DECLARE 
ASG$HDR 
LITERALLY 
LINK 
ADDRESS, 


LENGTH 
ADDRESS, 


TYPE 
8YTE, 


HOHE$EXCHANGE 
ADDRESS, 


RESPONSE$EXCHANGE 
ADDRESS'; 


DECLARE 
MSG$DESCRIPTOR 
LITERALLY 
'STRUCTURE( 


MSC$HDR, 
ROIAINDER( 
1) 
BYTE)'; 


UNCLUDE(:Fl:INTRPT,EXT) 
RGEND!: 


PROCEDURE 
EXTERNAL; 


END 
ROENDI; 


RQELVL: 


PROCEDURE 
(LEVEL) 
EXTERNAL; 
DECLARE 
LEVEL 
BUE; 


END 
RQDLVL; 


ROSETV 
: 


PROCEDURE 
(PROC,LEVEL) 
EXTERNAL; 


DECLARE 
PROC 
ADDRESS; 


DECLARE 
LEVEL 
BYTE; 


UNCLUD£( 
:r1:SYNCH,EXT) 


ROSEND: 


PROCEDURE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
EXTERNAL; 


DECLARE 
(EXCHANGE$POINTER,MESSAGE$POINTEfl) 
ADDRESS; 


Additional 
macros 
are declared 
to aid in the 
use 


of the SBC 711 analog-to-digital 
board. 


SSC 
711 
ANALOG 
TO 
DIGITAL 
BOARD 


" 
DECLARE 
ADC$BASE 
ADDRESS 
AT 
(OnDDH); 


D£CLARE 
CDHHAND$R£GISTER 
BUE 
AT 
(.ADC$SASE+O); 


DECLAAE 
STATUS$REGISTER 
BYTE 
AT 
(.ADC$BASE+D); 
DECLARE 
i"IRST$CHANNELtREGISTER 
BYTE 
AT 
(,ADC$BASE+1); 


DECLARE 
LAST$CHANNEL$REGISTER 
BYTE 
AT 
(. 
ADC$BASE+2); 


DECLARE 
CLEAR$lNTERRUPT$REQUEST 
BYTE 
AT 
(.ADC$8ASE+); 
DECLARE 
ADC$DATA$REGISTER 
ADDRESS 
AT 
(,ADC$BASE+4); 


DECLARE 
GO$8IT 
LITERALLY 
'1'; 


DECLARE 
AUTO$lNCREMENT$ENABLE 
LITERALLY' 
2'; 
DECLARE 
BUSY 
LITERALLY 
'e', 


DECLARE 
EOSUNTERRUPT$ENABLE 
LITERALLY' 
lOH', 
DECLARE 
EOC$lNTERRUPT$ENABLE 
LITERALLY' 
20H'; 


DECLARE 
END$OF$SCAN 
LITERALLY' 
40H'; 


DECLARE 
END$OF$CONVERSION 
LITERALLY 
'eOH'; 


The 
exchange 
descriptors 
and 
the 
interrupt 
ex- 
change descriptors 
are declared. 


DECLARE 
DUMMY 
EXCHANGE.DESCRIPTCR 
PUBLIC; 
DECLARE 
RET$PULSE 
EXCHANGE.DESCRIPTOR 
PUBLIC; 
DECLARE 
GO$PULSE 
EXCHANGE$DESCRIPTOR 
PUBLIC, 
DECLARE 
TRIGGER 
EXCHANGE$DESCRIPTOR 
PUBLIC; 
DECLARE 
RET$TRIG 
EXCHANGE$DESCRIPTOR 
PUBLIC; 


DECLARE 
ROL2EX 
INT$EXCHANGE$DESCRIPTOR, 


The 
CONTROL 
task 
uses an external 
data 
struc- 


ture 
to 
obtain 
operating 
parameters. 
This 
data 


structure 
(BOX$P ARAMS) 
has an exchange 
asso- 


ciated 
with 
it (T$P ARAM$LOCK) 
that 
is used to 


provide 
mutual 
exclusion, 
ensuring 
that 
only one 


task accesses the data structure 
at a time. 


DECLARE 
T$PARAM$LOCK 
EXCHANGE$DESCRIPTOR 
EXTERNAL, 


DECLARE 
BOX$PARAMS( 
5) 
STRUCTURE( 


CHANNEL 
BYTE, 


SET$POINT 
ADDRESS, 


ERROR 
ADDRESS, 


OFFSET 
ADDRESS, 
SAHPLES 
ADDRESS, 


COUNT 
ADDRESS, 


ACCUM 
ADDRESS, 


READING 
ADDRESS) 
EXTERNAL, 


TICKER, 
the 
scheduler 
task, 
has an initialization 


sequence 
in which 
it sets 
up 
two 
messages 
and 


sends them 
to the RET$PULSE 
exchange. 
Then it 


enters 
an 
infinite 
loop 
where 
it 
waits 
on 
the 
DUMMY 
exchange 
for 
250 
milliseconds. 
After 


the timed 
wait is complete, 
TICKER 
passes a mes- 


sage from 
the RET$PULSE 
exchange 
to the GO$- 


PULSE 
exchange. 
In effect 
this 
is a handshake, 
checking 
to see that 
the ADC 
task has completed 


its last 
operation 
and then 
signaling 
it to perform 


another. 


56 
TICKERSTASK: 


PROCEDURE 
PUBL1C; 


57 
DECLARE 
MSG 
ADDRESS; 
58 
DECLARE 
PULSE$I1SG(Z) 
STRUCTURE 
( 


HSGSHOR 
): 


59 
PUL$ESHSG(O).LENGTH, 
PULSESHSG( 
t) .LENGTH 
: 
SIZt( 
PULSESI1SG(O); 


60 
PULSE$I1SG(O). 
TYPE, 
PULSE$HSG{l).T"1PE 
= 
65: 
61 
CALL 
RQSEND(. 
AtT$PULSE,. 
PULSE$HSG( 
OJ); 


62 
CALL 
RQSEND(. 
RETS PULSE,. 
PULSESI1SG( 
1»; 


63 
00 
FOREVER: 
611 
HSG 
= 
RQWAIT(. 
DUHMY ,5); 
55 
HSC 
= 
RQWAlT(.IlET$PULSE,O): 


1S6 
CALL 
RQSEND( 
.GOSPULSE,HSC); 
67 
END: 


Scheduled 
by TICKER, 
the ADC task performs 
the 
A/D sampling. 
It begins by setting 
up TRIGGER$- 


MSG and 
enabling 
the 
level 2 interrupt 
from 
the 
A/D. 
Inside 
the 
ADC task 
continuous 
loop, 
mes- 


sages are passed 
from 
the GO$PULSE 
exchange 
to 
the 
RET$PULSE 
exchange. 
Then 
it waits 
for ac- 


cess to 
the 
BOX$PARAMS 
data 
structure. 
When 


the ADC task has access, it loops through 
the A/D 


channels, 
accumulating 
readings in BOX$PARAMS. 


After 
all the 
A/D 
channels 
are sampled 
and 
the 


BOX$PARAMS 
readings 
updated, 
the LOCK$MSG 
is returned 
to 
the 
T$P ARAM$LOCK 
exchange. 


The 
ADC task 
concludes 
the 
continuous 
loop 
by 
handshaking 
a message 
with 
the CONTROL 
task. 


ADCSTASK: 


PROCEDURE 
PUBLIC; 


DECLARE 
TRIOGER$HSG 
STRUCTURE 
( 


MSO$HOR 
l; 


DECLARE 
(T$H$G,HSG,LOCK$MSG) 
ADDRESS; 


DECLARE 
J 
BYTE: 


DECLARE 
GAIN 
LITERALLY' 
00'; 
DECLARE 
"'CIINtS 
LITERALLY' 
S'; 


TRIGGER$HSG.LENGTH 
: 
SIZE(TRIGGER$MSG); 


TRIOOER$MSO.TYPE 
: 
65; 


CALL 
RQSEND(, 
RETUUG,. 
TRIGOEIl$KSG); 


CALL 
RQELVL(2); 


DO 
FOREVER; 


MSO 
: 
RQWAIT( 
.CO$PULSE,o); 


CALL 
RQSEND( 
.REUPULSE,MSO); 
t.OCIi:$MSG 
: 
RQWAIT( 
.T$PARAI1$LOCIt,O}; 


DO 
I 
: 
0 
TO 
N$CHNLS-1: 


F!RSTSCHANNEL$REGISTER 
: 
BOX$PARAMS( 
I) 
.CHANNEL 
• 
ROL( 
GAIN 
,6}; 


COI'1MAHD$JIEGISTER 
: 
OO$BIT 


OR 
EOctlNTERRUPUENABLE; 
MSG: 
RQWAIT(.RQL2EX,O): 


COI'1MAND$REGlSTER 
, 
0: 


BOX$PARAMS{ 
I) 
• ACCUM 
• 
BOX$PARAI1S{ 
I) 
• ACCUM 


.• 
ADC$OATA$REOISTER: 
END: 


CALL 
RQSEND( 
.UPARAMSLOCI(,LOCK$MSG): 


T$MSO 
, 
RQWAIT{ 
.REUTRIG,O): 


CALL 
RQS£IfD( 
.TRIGOER,T$MSG}: 


END; 


The CONTROL 
task waits for a message 
from 
the 


ADC 
task 
signaling 
that 
AID readings 
have been 


taken 
and are ready 
for further 
processing. 
It com- 


pletes 
the 
handshake 
by 
sending 
the 
message 
to 


the 
RET$TRIG 
exchange. 
Then, 
as in the 
ADC 


task, 
accesses 
the 
BOX$PARAMS 
data 
structure. 


Inside 
the 
next 
loop, 
the 
readings 
are 
averaged, 


scaled, 
offset, 
and 
tested. 
Appropriate 
action 
is 


taken 
to turn 
the heating 
elements 
on or off. The 


loop 
concludes 
by 
returning 
the 
message 
to 
the 


T$PARAM$LOCK 
exchange. 


95 
COIfTROLUASl(: 


PROCEDURE 
PUBLIC: 


96 
DECLARE 
(LOCK$MSO, 
T ,HSO) 
ADDRESS; 
97 
DECLARE 
I 
BYTE: 


98 
DECLARE 
NCHNLS 
LITERALLY' 
5'; 


99 
DECLARE 
TURN$l.H1P$ON 


LITERALLY 
'OUTPUT(OE7H).SHL(I,1}': 
DECLARE 
tURN$LAMP$OFF 
LITERALLY 
'OUYPUT(OE7H) 
,SHL{ 
I, 
I) 
.1' 
: 


DECLARE 
SETUP$8255 
LITERALLY 
'OUTPUT( 
OE7H) 
,8oH; 


OUTPUT(OE6H):OFFH': 


DO 
FOREVER; 


I'1sa: 
FlQ'oIAIT(.TRIOOER,O): 
CALL 
ROSEJrlD( 
.RETUR!O,MSG): 


LOCUMSO: 
RQWAIT(. 
TSPARAM$LOCI( 
,0): 
DO 
I 
: 
0 
TO 
JrlCHJrlLS_l: 


BOX$PARAHS( 
I) 
,COUNT 
= 
BOX$PARAI'1S( 
I) 
.COUIfT 
• 
I: 
IF 
BOUPARAHS( 
Il,COUNT 


: 
BOX$PARAHS( 
I) 
.SAMPLES 
THEN 
DO: 


T. 
BOXSPARAHS( 
I) 
,READIlfC 
= 
(BOX$PARU1S(I).ACCUH 


IBOXHARAHS( 
I) 
.SAHPLES) 
I 
38 


.• 
BOX$PARAHS( 
I).OFFSET; 
IF 
T 
(: 
BOX$PARAMS(I).SEUPOINT 


- 
BOXHARAMS( 
I).ERROR 
THEN 
TURNSLAMP$ON: 
ELSE 
IF 
T 
): 
BOX$PARAMS(I).SET$POINT 
• 
BOX$PAIlAHS( 
I). 
ERROR 
THEN 
TURN$LAI'1P$OFF: 


BOX$PARAI'1S( 
I) 
.ACCUI'1, 
BOXSPARAI'1S( 
I) 
.COUNT 
: 
0; 
END: 
END: 


CALL 
RQSEND(, 
U 
PARAI'1$LOCK, 
LOCK$HSC) 
; 


END; 


SUMMARY /CONCLUSIONS 


The 
purpose 
of this 
application 
note 
is to intro- 


duce 
you 
to the 
Intel 
RMX/80, 
Real-Time 
Multi- 


tasking 
Executive. 
The 
general 
framework 
of 


RMX/80 
was discussed, 
including 
the nucleus 
and 


extensions. 


This 
application 
note 
described 
the steps involved 


in using 
RMX/80. 
Key emphasis 
has been 
placed 


on the need to fully define the tasks and exchanges 
in your application 
using graphic 
notation. 


Applications 
have been 
presented 
to demonstrate 


task 
communication, 
synchronization, 
and mutual 


exclusion 
in a minimal 
terminal 
handler 
and 
an 


analog 
subsystem. 
The 
tasks 
responded 
to 
real- 
time 
asynchronous 
events 
such 
as 
USART 
and 


A/D interrupts 
. 


RMX/80 
represents 
a significant 
step in the sophis- 
tication 
of 
microcomputer 
software. 
Its 
ease 
of 


use, 
flexibility, 
and 
power 
should 
enable 
you 
to 


quickly 
implement 
real-time 
software 
for 
your 


applications. 


DECLARE 
TRUE 
LITERALLY 
'0FFH'; 


DECLARE 
FOREVER 
LITERALLY 
'WHILE TRUE'; 


/* SPECIAL 
DECLARE 


B.E.LL 
LF 
CR 
CONTROL$R 
CONTROL$X 
Ese 
RUBOU'!' 


LI'!'ERALLY'07H', 
LITERALLY 
'0AB', 
LITERALLY 
'0DH', 
LITERALLY 
'12H', 
LITERALLY 
'18h', 
LITERALLY 
'lBH', 
LI'I'ERALLY '7FH'; 


DECLARE 
EXCHANGE$DESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 
MESSAGE$hEAD 
ADDRESS, 


MESSAGE$TAIL 
ADDRESS, 


TASK$HEAD 
ADDRESS, 


TASK$TAIL 
ADDRESS, 
EXCHANGE$LINK 
ADDRESS) '; 


DECLARE 
INT$EXCtiA~GE$DESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 
MESSAGE$HEAD 
ADDRESS, 


MESSAGE$TAIL 
ADDRESS, 


TASK$HEAD 
ADDRESS, 


TASK$TAIL 
ADDRESS, 


EXChANG.E.$LI~KADDRESS, 
LINK 
ADDRESS, 
LENG'!'HADDRESS, 
TYPE 
BYTE) ,; 


DECLARE 
Th$MSG 
LITERALLY 
'STRUCTURE ( 
LINK 
ADDRESS, 
LE~GTH 
ADDRESS, 


TYPE 
BYTt., 


HOME$.E.XCBANGE ADDRBSS, 
RESPO~3E$EXChANGE 
ADDRESS, 


S'!'AT'US 
ADDRESS, 


BUFFER$ADDRESS 
ADDRESS, 


COUNT 
ADDRESS, 


ACTUAL 
ADDRESS) '; 


/* 
8253 
PORT 
ADDRESSES. 
*/ 
DECLARE 
A8253$MODE 
LITERALLY 
'0DFh'; 


DECLARE 
A6253$CTR2 
LITERALLY 
'0D.E.h'; 


19 
1 


20 
2 
21 
2 


22 
1 


23 
2 
24 
2 


25 
1 


26 
2 
27 
2 


28 
1 


29 
1 


30 
1 


31 
1 


32 
1 


33 
2 
34 
2 


/* 
8253 
COMIVJANDS. 
*/ 
DECLARE 
SELECT$2 
LITERALLY 
'1~~000008'; 
DECLARE 
RL$80'I'8 
LITERALLY 
'001100008'; 
DECLARE 
MODE$3 
LITERALLY 
'000001108'; 
DECLARE 
82400 
LITBRALLY 
'001C8'; 


/* 
8251 
PORT 
ADDRESSES. 
*/ 
DECLARE 
USART$IN 
LITERALLY 
'0ECH', 
USART$OUT 
LITERALLY 
'0ECh', 
USART$CONTROL 
LITERALLY 
'0EDh'; 


/* 
8251 
MODES. 
*/ 
DECLARE 
STOP$l 
LITERALLY 
'01000000B'; 
DECLARE 
CL8 
LITERALLY 
'00001100B'; 
DECLARE 
RATE$16X 
LITERALLY 
'00000010B'; 


/* 
8251 
COMl>1ANDS. 
*/ 
DECLARE 
USART$RESET 
RTS 
ERROR$RESET 
RXE 
DTR 
TXEN 


LI'I'ERALLY 
LITERALLY 
LI'I'ERALLY 
LI'l'ERALLY 
LITERALLY 
LITERALLY 


'010000008', 
'001000008', 
'00LtJ10000B', 
'000001008', 
'000000108', 
'000000018'; 


RI..!SEND: 
PROCEDURE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
EXTERNAL; 


DECLARE 
(EXCHANGE$POINTER,M£SSAGE$POINTER) 
ADDRESS; 
END 
R!,JSEND; 


R\.iWA I 'I' : 
PROCEDURE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS 
EXTERNAL; 
DECLARE 
(EXCHANGE$POINTER,DELAY) 
ACDRESS; 
END 
R\.iWAI'I'; 


R\.iE.LVL: 
PROCEDURE 
(LEVEL) 
EXTERNAL; 
DECLARE 
LEVEL 
BYTE; 
END 
R\.iBLVL; 


DECLARE 
RQINPX 
EXCHANGE$DESCRIPTOR 
PUBLIC; 
DECLARE 
R\.iOUTX EXCHANGE$DESCRIPTOR 
PUBLIC; 


DECLARE 
R~L6EX 
INT$EXChANGE$DESCRIPTOR 
PUBLIC; 
DECLARE 
R\.iL7EX INT$EXChANGE$DESCRIPTOR 
PUBLIC; 


INI'I'IALIZA'l'ION: 
PROCEDURE; 


OUTPUT(A8253$MODE) 
OU'l'PUT(A8253$CTR2) 
SELEC'l'$2 OR 
RL$BOTh 
OR 
MODE$3; 


LOW (B 2 4 0 0) 
; 


37 
2 
38 
2 
39 
2 


40 
2 


41 
1 


42 
2 
43 
2 
44 
2 
45 
2 


46 
2 


47 
3 
48 
3 
4<;; 
3 
50 
3 


51 
2 


52 
2 
53 
2 


54 
2 
55 
3 
56 
3 
57 
3 
58 
3 
59 
3 
610 
4 
61 
4 
62 
4 


63 
5 
64 
5 


65 
5 
66 
6 
67 
6 
68 
6 
69 
5 


70 
4 


71 
5 


72 
5 


73 
6 
74 
6 
75 
6 


76 
6 
77 
6 


78 
5 


OUTPUT(A8253$CTR2) 
= bIGb(B2400); 
OUTPUT(USART$CONTROL), 
OUTPUT (USART$CONTROL) , 
OUTPUT (USART$CONTROL) , 
OUTPUT (USART$CONTROL) 
OUTPUT (USART$CONTROL) 
OUTPUT (USART$CONTROL) 
OU'l'PUT(USAR'I'$CONTRGL) 


0; 
USART$RESE'I'; 
STOP$l 
OR 
CL8 
OR 
RA'I'E$16X; 


RTS 
OR 
ERROR$RESET 
OR 


RXE OR 
DTR 
OR 
TXEN; 


RD$I'UN: 
PROCEDURE 
PUBLIC; 
DECLARE 
(MSGPTR,INTMSG,BUF$ADDRESS) 
ADDRESS; 


DECLARE 
(CHAR,PTR,I) 
BYTE; 
DECLARE 
MSG 
BASED 
MSGPTR 
TH$MSG; 
DECLARE 
(BUF BASED 
BUF$ADDRESS) 
(1) BYTE; 


ECHO$CHAR: 
PROCEDURE 
(CHAR); 
OECLARE 
CHAR 
BYTE; 
INTMSG 
= RQWAIT(.RQL7EX,0); 
OUTPUT (USART$OUT) 
= CHAR; 
END 
ECflO$ChAR; 


CALL 
Rl,JELVL(6); 


CALL 
R\.iELVL(7); 


DO 
FOREVER; 


MSGPTR 
= RQWAIT(.RQI~PX,0); 


BUF$ADDRLSS 
= MSG.BUFFER$ADDRESS 
- 1; 
PTR 
= 0; 


ChAR 
= 
I'llo'I'CR.; 


DO WHILE 
ChAR 
<> 
CR; 
INTMSG 
= R\.iWAIT(.RQL6EX,0); 
IF 
(CHAR 
:= 
INPUT(USART$IN) 
AND 
7FH) 
DO; 
IF PTR = 0 TBEN 
CALL 
ECHO$CHAR(BELL); 
ELSE 
DO; 
CALL 
ECHO$CHAR(BUF(PTR)); 
PTR = PTR 
- 1; 
END; 
END; 
ELSE 
DO; 
IF ChAR 
= CONTROL$X 
ThEN 
DO; 
CALL 
ECHO$CHAR('#'); 
CALL 
ECHO$CHAR(CR); 
CALL 
ECfiO$CHAR(LF); 
P'l'R 
= 
0; 
END; 
ELSE 
DO; 


79 
6 


80 
6 


81 
7 


82 
7 


83 
7 


84 
8 
85 
8 


86 
7 


87 
6 


88 
7 


89 
7 


90 
7 


91 
8 
n 
8 


93 
8 
94 
7 


95 
7 


96 
8 


97 
8 
98 
8 
99 
7 


HH:J 
7 


101 
6 


102 
5 


103 
4 


104 
3 


HiS 
3 


Hl6 
3 


HJ7 
3 


108 
3 
109 
3 


IHJ 
3 


111 
2 


112 
1 


113 
2 
114 
2 


115 
2 
116 
2 


117 
2 


118 
2 


119 
3 


12LQ 
3 
121 
3 
122 
4 
123 
4 
124 
4 


125 
3 
126 
3 
127 
3 
128 
3 
129 
2 
130 
1 


IF ChAR 
= CONTROL$R 
THEN 
DO: 
CALL 
ECHO$CHAR(CR): 
CALL 
ECHO$CHAR(LF): 
DO 
I = 1 TO 
PTR: 
CALL 
ECHO$CHAR(BUF(I)): 
END: 
END: 
ELSE 
DO: 
IF PTR 
< 
MSG.COUNT 
THEN 
BUF(PTR 
:= PTR+l) 
= CHAR: 
ELSE 
DO: 
IF CHAR 
<> 
CR THEN 
CHAR 
= BE.LL: 
END: 
IF CBAR 
= ESC TBEN 


DO: 
CALL 
ECHO$CHAR('$'): 
CHAR 
= CR: 
END: 
CALL 
ECBO$ChAR(CHAR): 
END; 


END: 
END: 
END: 
IF PTR 
< 
MSG.COU~T 
THEN 
BUF(PTR:=PTR+l) 
= LF: 


MSG.ACTUAL 
= PTR: 
MSG.STATUS 
= 0: 
CALL 
R~SEND(MSG.RESPONSE$EXChANGE,MSGPTR): 


CALL 
ECHO$CBAR(LF): 
END: 
END 
RD$MIN: 


wR$MIN: 
PROCEDURE 
PUBLIC: 
DECLARE 
(MSGPTR,INTMSG,BUF$ADDRE.SS) 
ADDRESS: 


DECLARE 
PTR 
BYTE: 
DECLARE 
MSG 
BASED 
MSGPTR 
TH$MSG: 
DECLARE 
(BUF BASED 
BUF$ADDRESS) 
(1) BY'I'E: 


DO 
r'0REVER: 


MSG~TR 
= RQwAIT(.RQOUTX,0): 
BUF$ADDR£SS 
= MSG.BUFFER$ADDR£SS 
- 1: 
DO PTR 
= 1 TO MSG.COUNT: 
INTMSG 
= RQwAIT(.RQL7EX,0): 


OUTPUT (USART$OUT) 
= BUF(PTR): 
END: 
MSG.ACTUAL 
= MSG.COUNT: 


HSG.S'l'A'I'liS 
= 0: 


CALL 
RQSEND(MSG.RESPONSE$EXCHANGE,MSGPTR): 
END: 
El''lD 
wR$lHN: 


END MINIMAL$TERMINAL$BANDLER: 


APPENDIXB 


WRMIN ASSEMBLY 
LANGUAGE 
LISTING 


LOC 
OBJ 
SEQ 
SOURCE 
STATEMENT 


1 
NA~IE 
WRMIN 
2 
EXTRN 
RQELVL,RQOUTX,RQWAIT,RQSEND 
3 
PUBLIC 
WRMIN,RQL7EX 


OOEC 
4 
DATOUT 
EQU 
OECH 
; 
USART 
OUTPUT 
PORT 
ADR 


5 
CSEG 
6 WRMIN: 


0000 
OE07 
7 
MVI 
C,7 


0002 
CDOOOO 
E 
8 
CALL 
RQELVL 
ENABLE 
INTERRUPT 
LVL 
7 


9 WRO: 


0005 
110000 
10 
LXI 
D,O 


0008 
010000 
E 
11 
LXI 
B,RQOUTX 


OOOB 
CDOOOO 
E 
12 
CALL 
RQWAIT 
WAIT 
FOR 
OUTPUT 
RQST 
OOOE 
E5 
13 
PUSH 
H 
PUSH 
MESSAGE 
ADDRESS 


OOOF 
110700 
14 
LXI 
D,7 


0012 
19 
15 
DAD 
D 


0013 
4E 
16 
MOV 
C,M 
GET 
RESPONSE 
EXCHANGE 
0014 
23 
17 
INX 
H 


0015 
46 
18 
MOV 
B,M 


0016 
23 
19 
INX 
H 


0017 
C5 
20 
PUSH 
B 
PUSH 
RESPONSE 
EXCHANGE 
0018 
3600 
21 
MVI 
M,O 
STATUS 
= 
0 
001A 
23 
22 
INX 
H 


001B 
3600 
23 
MVI 
M,O 


001D 
23 
24 
INX 
H 


001E 
5E 
25 
MOV 
E,M 
GET 
BUFFER 
ADR 
IN 
DE 
001F 
23 
26 
INX 
H 


0020 
56 
27 
MOV 
D,M 


0021 
23 
28 
INX 
H 


0022 
4E 
29 
MOV 
C,M 
GET 
COUNT 
IN 
BC 
0023 
23 
30 
INX 
H 


0024 
46 
31 
MOV 
B,M 


0025 
23 
32 
INX 
H 


0026 
71 
33 
MOV 
M,C 
ACTUAL 
COUNT 
0027 
23 
34 
INX 
H 


0028 
70 
35 
MOV 
M,B 


36 
WR 1 : 


0029 
78 
37 
MOV 
A,B 


002A 
B1 
38 
ORA 
C 


002B 
CA4300 
C 
39 
JZ 
WR2 
EXIT 
LOOP 
IF 
COUNT 
= 
0 
002E 
C5 
40 
PUSH 
B 


002F 
D5 
41 
PUSH 
D 


0030 
110000 
42 
LXI 
D,O 


0033 
010000 
D 
43 
LX I 
B,RQL7EX 


0036 
CDOOOO 
E 
44 
CALL 
RQWAIT 
WAIT 
FOR 
TXRDY 
INTRPT 
0039 
D1 
45 
POP 
D 


003A 
C1 
46 
POP 
B 


003B 
1A 
47 
LDAX 
D 


003C 
13 
48 
INX 
D 


003D 
D3EC 
49 
OUT 
DATOUT 
TRANSMIT 
NEXT 
CHAR 
003F 
OB 
50 
DCX 
B 


0040 
C32900 
C 
51 
JMP 
WR1 
52 
WR2: 


2-25 
AFN-Q1931A 


0043 
C1 
53 
POP 
B 
BC 
= 
RESPONSE 
EXCHANGE 
0044 
D1 
54 
POP 
D 
DE 
= 
MSG 
ADDR£SS 
0045 
CDOOOO 
E 
55 
CALL 
RQSEND 
SEND 
MSG 
TO 
RESP. 
EXCH 
0048 
C30500 
C 
56 
JMP 
WRO 


57 
58 
DSEG 


59 
RQL7EX: 


OOOF 
60 
DS 
15 


61 
62 
END 


ATOD: 
DO; 


$ INCLUDE( 
:F 1 :COMMON, 
ELT) 
DECLARE 
TRUE 
LITERALLY 
'OFFH'; 
DECLARE 
FALSE 
LITERALLY' 
DOH'; 
DECLARE 
BOOLEAN 
LITERALLY 
'BYTE'; 
DECLARE 
FOREVER 
LITERALLY 
'WHILE 
1'; 


$INCLUDE( 
:F1 :EXCH,ELT) 


DECLARE 
EXCHANGE$DESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 


MESSAGE$HEAD 
ADDRESS, 


MESSAGE$TAIL 
ADDRESS, 
TASK$HEAD 
ADDRESS, 
TASK$TAIL 
ADDRESS, 
EXCHANGE$LINK 
ADDRESS)'; 


$INCLUDE( 
:F1 :IED.ELT) 
DECLARE 
INT$EXCHANGE$DESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 
MESSAGE$HEAD 
ADDRESS, 


MESSAGE$TAIL 
ADDRESS, 
TASK$HEAD 
ADDRESS, 
TASK$TAIL 
ADDRESS, 
EXCHANGE$LINK 
ADDRESS, 
LINK 
ADDRESS, 


LENGTH 
ADDRESS, 
TYPE 
BYTE)'; 


$INCLUDE( 
:F1 :MSG,ELT) 


DECLARE 
MSG$HDR 
LITERALLY 
, 


LINK 
ADDRESS, 
LENGTH 
ADDRESS, 
TYPE 
BYTE, 


HOME$EXCHANGE 
ADDRESS, 


RESPONSE$EXCHANGE 
ADDRESS'; 


DECLARE 
MSG$DESCRIPTOR 
LITERALLY 
'STRUCTURE( 


MSG$HDR, 
REMAINDER( 
1) 
BYTE)'; 


$INCLUDE( 
:F1 :INTRPT,EXT) 


RQENDI: 
PROCEDURE 
EXTERNAL; 


RQELVL: 
PROCEDURE 
(LEVEL) 
EXTERNAL; 
DECLARE 
LEVEL 
BYTE; 


RQDLVL: 


PROCEDURE 
(LEVEL) 
EXTERNAL; 


DECLARE 
LEVEL 
BYTE; 


RQSETV: 
PROCEDURE 
(PROC,LEVEL) 
EXTERNAL; 


DECLARE 
PROC 
ADDRESS; 


DECLARE 
LEVEL 
BYTE; 


$INCLUDE( 
:F1 :SYNCH.EXT) 
RQSEND: 
PROCEDURE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
EXTERNAL; 
DECLARE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
ADDRESS; 


RQWAIT: 
PROCEDURE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS 
EXTERNAL; 


DECLARE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS; 


RQACPT: 


PROCEDURE 
(EXCHANGE$POINTER) 
ADDRESS 
EXTERNAL; 
DECLARE 
EXCHANGE$POINTER 
ADDRESS; 


RQISND: 
PROCEDURE 
(IED$PTR) 
EXTERNAL; 


DECLARE 
IED$PTR 
ADDRESS; 


SBC 
711 
ANALOG 
TO 
DIGITAL 
BOARD 


*/ 
DECLARE 
ADC$BASE 
ADDRESS 
AT 
(OF700H); 


DECLARE 
COMMAND$REGISTER 
BYTE 
AT 
(.ADC$BASE+O); 


DECLARE 
STATUS$REGISTER 
BYTE 
AT 
(.ADC$BASE+O); 


DECLARE 
FIRST$CHANNEL$REGISTER 
BYTE 
AT 
(.ADC$BASE+1); 


DECLARE 
LAST$CHANNEL$REGISTER 
BYTE 
AT 
(.ADC$BASE+2); 


DECLARE 
CLEAR$INTERRUPT$REQUEST 
BYTE 
AT 
(.ADC$BASE+3); 


DECLARE 
ADC$DATA$REGISTER 
ADDRESS 
AT 
(.ADC$BASE+4); 


DECLARE 
GO$BIT 
LITERALLY' 
l' ; 
DECLARE 
AUTO$INCREMENT$ENABLE 
LITERALLY 
'2'; 


DECLARE 
BUSY 
LITERALLY 
'8'; 


DECLARE 
EOS$INTERRUPT$ENABLE 
LITERALLY' 
10H'; 
DECLARE 
EOC$INTERRUPT$ENABLE 
LITERALLY 
'20H'; 
DECLARE 
END$OF$SCAN 
LITERALLY 
'40H'; 


56 


51 
2 
58 
2 


59 
2 


60 
2 


61 
2 
62 
2 


63 
2 
64 
3 
65 
3 
66 
3 
61 
3 


68 
2 


69 


10 
2 


11 
2 
12 
2 
13 
2 
14 
2 


15 
2 
16 
2 
11 
2 
18 
2 


DECLARE 
DUMMY 
EXCHANGE$DESCRIPTOR 
PUBLIC; 
DECLARE 
RET$PULSE 
EXCHANGE$DESCRIPTOR 
PUBLIC; 


DECLARE 
GO$PULSE 
EXCHANGE$DESCRIPTOR 
PUBLIC; 
DECLARE 
TRIGGER 
EXCHANGE$DESCRIPTOR 
PUBLIC; 
DECLARE 
RET$TRIG 
EXCHANGE$DESCRIPTOR 
PUBLIC; 


DECLARE 
RQL2EX 
INT$EXCHANGE$DESCRIPTOR; 


DECLARE 
T$PARAM$LOCK 
EXCHANGE$DESCRIPTOR 
EXTERNAL; 


DECLARE 
BOX$PARAMS(5) 
STRUCTURE( 
CHANNEL 
BYTE, 
SET$POINT 
ADDRESS, 


ERROR 
ADDRESS, 
OFFSET 
ADDRESS, 
SAMPLES 
ADDRESS, 


COUNT 
ADDRESS, 
ACCUM 
ADDRESS, 
READING 
ADDRESS) 
EXTERNAL; 


TICKER$TASK: 
PROCEDURE 
PUBLIC; 
DECLARE 
MSG 
ADDRESS; 


DECLARE 
PULSE$MSG(2) 
STRUCTURE 
( 
MSG$HDR 
); 


PULSE$MSG(O).LENGTH, 
PULSE$MSG(1).LENGTH 
= 
SIZE(PULSE$MSG(O»; 


PULSE$MSG(O).TYPE, 
PULSE$MSG( 
1) .TYPE 
= 
65; 


CALL 
RQSEND(, 
RET$ PULSE, 
•PULSE$MSG( 
0» 
; 
CALL 
RQSEND(, 
RET$ PULSE, 
•PULSE$MSG( 
1» 
; 


DO 
FOREVER; 
MSG 
= 
RQWAIT(.DUMMY,5); 


MSG 
= 
RQWAIT( 
.RET$PULSE,O); 
CALL 
RQSEND(.GO$PULSE,MSG); 
END; 


ADC$TASK: 
PROCEDURE 
PUBLIC; 


DECLARE 
TRIGGER$MSG 
STRUCTURE 
( 
MSG$HDR 
); 
DECLARE 
(T$MSG,MSG,LOCK$MSG) 
ADDRESS; 


DECLARE 
I 
BYTE; 


DECLARE 
GAIN 
LITERALLY 
'00'; 


DECLARE 
N$CHNLS 
LITERALLY 
'5'; 


TRIGGER$MSG.LENGTH 
= 
SIZE(TRIGGER$MSG); 
TRIGGER$MSG.TYPE 
= 
65; 
CALL 
RQSEND(.RET$TRIG,.TRIGGER$MSG); 
CALL 
RQELVL(2); 


104 
105 
106 
107 
108 
109 
110 


111 
112 


DO 
FOREVER; 
MSG 
= 
RQWAIT( 
.GO$PULSE,O); 
CALL 
RQSEND( 
.RET$PULSE,MSG); 
LOCK$MSG 
= 
RQWAIT( 
.T$PARAM$LOCK,O); 
DO 
I 
= 
0 
TO 
N$CHNLS-1; 
FIRST$CHANNEL$REGISTER 
= 
BOX$PARAMS(I).CHANNEL 
+ 
ROL(GAIN,6); 


COMMAND$REGISTER 
= 
GO$BIT 
OR 
EOC$INTERRUPT$ENABLE; 


MSG 
= 
RQWAIT( 
.RQL2EX,0); 
COMMAND$REGISTER 
= 
0; 
BOX$PARAMS(I).ACCUM 
= 
BOX$PARAMS(I).ACCUM 
+ 
ADC$DATA$REGISTER; 


END; 
CALL 
RQSEND(.T$PARAM$LOCK,LOCK$MSG); 
T$MSG 
= 
RQWAIT( 
.RET$TRIG,O); 
CALL 
RQSEND( 
.TRIGGER,T$MSG); 
END; 


CONTROL$TASK: 
PROCEDURE 
PUBLIC; 
DECLARE 
(LOCK$MSG,T,MSG) 
ADDRESS; 
DECLARE 
I 
BYTE; 
DECLARE 
NCHNLS 
LITERALLY 
'5'; 
DECLARE 
TURN$LAMP$ON 
LITERALLY 
'OUTPUT(OE7H)=SHL(I,1)'; 
DECLARE 
TURN$LAMP$OFF 
LITERALLY 
'OUTPUT(OE7H)=SHL(I,1)+1'; 
DECLARE 
SETUP$8255 
LITERALLY 
'OUTPUT(OE7H)=80H; 


OUTPUT( 
OE6H) =OFFH' 
; 


DO 
FOREVER; 
MSG 
= 
RQWAIT( 
.TRIGGER,O); 
CALL 
RQSEND( 
.RET$TRIG,MSG); 
LOCK$MSG= 
RQWAIT(.T$PARAM$LOCK,O); 
DO 
I 
= 
0 
TO 
NCHNLS-1; 
BOX$PARAMS(I).COUNT 
= 
BOX$PARAMS(I).COUNT 
+ 
1; 


IF 
BOX$PARAMS( 
I) .COUNT 
= 
BOX$PARAMS(I).SAMPLES 
THEN 
DO; 
T, 
BOX$PARAMS( 
1) .READING 
= 
(BOX$PARAMS(I).ACCUM 
/BOX$PARAMS(I).SAMPLES) 
/ 
38 
+ 
BOX$PARAMS(I).OFFSET; 
IF 
T 
<= 
BOX$PARAMS(I).SET$POINT 
- 
BOX$PARAMS(I).ERROR 
THEN 
TURN$LAMP$ON; 
ELSE 
IF 
T 
>= 
BOX$PARAMS(I).SET$POINT 
+ 
BOX$PARAMS(I).ERROR 
THEN 


118 
119 


120 
121 


TURN$LAMP$OFF; 
BOX$PARAMS( 
I) ,ACCUM, 


BOX$PARAMS( 
I) ,COUNT 
END; 
END; 


CALL 
RQSEND( 
,T$PARAM$LOCK,LOCK$MSG); 


END; 
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I. INTRODUCTION 


In March 
of 1978, 
Intel 
announced 
the availability 
of a 


resident 
FORTRAN 
compiler 
for 
the 
Intellec'" 
Micro- 


computer 
Development 
System. 
In November 
of 1978, 


Intel 
announced 
the availability 
of a run-time 
package 


to 
support 
the 
execution 
of 
FORTRAN-80 
compiled 


programs 
in the RMX/80™ 
environment. 
With 
this sup- 


port 
package, 
user's 
of Intel's 
complete 
line of iSBCTM 


Single 
Board 
Computer 
products 
can 
benefit 
from 
the 
full 
set of I/O 
and 
math 
capabilities 
provided 
by the 
FORTRAN-80 
language. 


This 
application 
note 
is 
intended 
to 
familiarize 
the 


reader 
with 
the 
features, 
benefits 
and 
usage 
of 
the 
FORTRAN-80 
package 
and 
RMX/80™ 
Executive. 
The 
reader 
who 
is unfamiliar 
with 
any 
of these 
topics 
is 
urged 
to refer 
to the related 
Intel 
publications 
listed 
in 


the front-piece. 


Following 
the overview, 
two application 
examples 
will 


be studied. 
In the first example, 
FORTRAN 
code is used 


in a "stand-alone" 
environment; 
i.e., without 
operating 


system 
support. 
The 
second 
example 
is a multitasking 


system 
managed 
by the RMX/80 
Executive 
which 
sup- 


ports 
standard 
I/O 
interfaces 
to the RMX/80 
Terminal 


Handler 
and Disk File System. 


II. OVERVIEW 


Intel's 
FORTRAN-80 
compiler 
is an implementation 
of 


the standard 
FORTRAN 
known 
as ANS FORTRA 
77 


approved 
by the American 
ational 
Standards 
Institute 
(ANSI) 
in April, 
1978. 
The 
implementation 
is of the 
FORTRAN 
77 subset, 
plus most 
of the full I/O capabil- 


ity and Intel 
defined 
extensions. 
For 
a fuller 
description 


of the implementation, 
consult 
the FORTRAN-80 
Pro- 
gramming Manual. 


FORTRAN-80 
is a high 
level 
applications 
program- 


ming 
language 
with 
flexible 
I/O handling 
and 
floating- 
point 
math 
instructions. 
With 
the 
FORTRAN-80 
lan- 
guage, 
the programmer 
can 
easily 
implement 
sophisti- 
cated 
applications 
involving 
scientific 
calculations, 


process 
and 
instrument 
control, 
test and 
measurement, 


and 
a host 
of other 
applications 
requiring 
the 
power 
and flexibility 
the FORTRAN-80 
language 
provides. 


With 
the 
addition 
of 
the 
iSBC 
801 
FORTRAN-80 


RUN-TIME 
PACKAGE 
for 
RMX/80 
SYSTEMS, 
the 


user 
who 
wishes 
to 
implement 
his 
application 
using 


Intel's 
Single 
Board 
Computers 
and 
the 
RMX/80 
Real: 


Time 
Multitasking 
Executive 
can take 
full advantage 
of 


the FORTRAN-80 
I/O and math 
capabilities. 
The pack- 
age allows 
the user to accelerate 
the run-time 
execution 


of FORTRAN-80 
coded 
mathematical 
formulae 
through 
special 
interfaces 
to 
the 
optional 
iSBC 
310™ 
High 


Speed 
Mathematics 
Unit. 
All disk 
and 
terminal 
I/O 
is 


interfaced 
directly 
to the RMX/80 
Disk File System 
and 
either 
the full 
or the 
minimal 
Terminal 
Handler. 
The 


libraries 
that 
comprise 
the iSBC package 
are 
construc- 
ted in a modular 
fashion, 
allowing 
the user to configure 


systems 
with 
as much 
or as little of the support 
libraries 
as needed 
for a given 
application. 


In order 
to effectively 
utilize 
the hardware 
and software 


products 
now available, 
it is important 
to design 
the ap- 
plication 
system 
from 
the top 
down. 
This 
implies 
that 
we need to think 
of an application 
in very general 
terms 
and 
then 
successively 
introduce 
more 
detail 
until 
we 


have 
program 
code 
as our 
final 
step. 
At each 
stage 
of 


the definition, 
we have 
to make 
decisions 
about 
the us- 


age and configuration 
of various 
products. 


The decision-making process that concerns itself with 
software can be shown as a tree (Figure I). The first 
decision that 
must be made is whether 
or not the 
RMX/SO Real-Time Multitasking Executive should be 
utilized. In general, this package will prove extremely 
useful if the application to be designed must respond to 
multiple 
asynchronous 
events, or contains 
multiple, 
semi-independent processes that could be executed in 
parallel, or has need of standard vendor supplied device 
drivers. If the application 
is very small and simple, 
handles few or no interrupts, has no need for parallel 
execution of multiple 
processes, and the designer is 
willing to supply his own 110 device drivers, the pro- 
gram may be able to execute without the support of an 
operating system. 


Whether the RMX/SOpackage is used or not, the system 
designer 
must 
now choose 
in which 
language 
or 


languages the programs should be coded. Each of the 
three languages shown is optimized for different pur- 
poses. The PUM-SO language is well suited for systems 
programming. 
The ASM-SOlanguage is best suited for 


applications 
requiring direct control of the computer 


(e.g., the registers and memory). The FORTRAN-SO 
language 
is highly 
desirable 
for those applications 


requiring 
mathematical 
calculations 
and 
formatted 


110. In many cases, the optimal solution will use a mix 
of two or even all three of these languages. 


I/O Capabilities 


After the decision has been made to use the FORTRAN- 
SO language for an application, 
various types of 110 
support are available to the user (see Figure 2). If the 
program code is to run without any support from an 
operating system, the user must supply drivers for any 
devices he wishes to include in his system. 


When designing an RMX/SOsystem, the iSBC SOI pack- 
age supplies the standard 
interface 
to the disk and 


terminal while the user may support additional devices 
in the same manner 
as the "stand 
alone" 
program 
would. The following sections expand on the topic of 
FORTRAN-SO110support. 


Port I/O 


The simplest and most direct method of performing 110 
in the FORTRAN-SOlanguage uses two pre-defined sub- 
routines, INPUT and OUTPUT. The example below il- 
lustrates the use of these subroutines to input bytes from 
and output bytes to any of the SOSOA/SOSSA110ports. 


INTERNAL 
BUFFER 
FORMATTING 


RMX·80™ 
DISK 
FILE 
SYSTEM 


RMXJ80™ 
TERMINAL 
HANDLER 


NON 
STANDARD 
DEVICES 


INTEGER· 
1 IVAL 


C 
C --PROGRAM THE 8255 PARALLEL I/O CHIP 
C--PORT# 
= EB; VALUE = 94 
C 
CALL OUTPUT (#OEBH, # 94H) 


C 
C --INPUT 8 BITS FROM PORT A INTO IVAL 
C -- PORT # = E8; VALUE 
INPUT TO IVAL 
C 


Port I/O is extremely useful in many applications. 
How- 


ever, this method requires the programmer 
to directly 
handle each and every byte. Also, it does not utilize the 
power of the FORTRAN-80 formatting 
routines. 


Internal Buffer Formatting 


One method of overcoming 
the shortcomings 
of Port 


I/O is to use character 
strings as "virtual 
devices." This 
is accomplished 
by specifying a character 
string as the 
unit number in a READ or WRITE statement. 
External 


routines can be used to fill the character 
strings with 
input for the READ statement and to output buffers that 
have been formatted 
by the WRITE statement. 
The ex- 


ample below shows the use of this method. 


SUBROUTINE 
EXAMPL 
CHARACTER·80 
BUFFER 


C 
C -- CALL DEVICE DRIVER TO GET BUFFER OF 
C -- CHARACTERS 
C 


C 
C --NOW READ FROM BUFFER INTO VARIABLES 
C -- UNDER FORMAT CONTROL 
C 
READ (BUFFER, 100) X, Y, Z 
100 FORMAT (FIO.3, FI2.4, FI3.5) 


• PROCESS DATA STORED I 
VARIABLES 


• 
X,Y,Z 


C 
C --WRITE RESULTS TO BUFFER 
C 
WRITE (BUFFER, 200) A, B, C, D 


200 FORMAT (4FI2.3) 
C 


C --CALL DEVICE DRIVER TO OUTPUT BUFFER 
C 


User Provided High-Level Drivers 


If an application 
requires only simple input (READ) and 
output 
(WRITE) 
capabilities, 
the previous 
method 
would probably be sufficient. If, however, the device(s) 
in the system are more complex, it may be necessary to 
perform other I/O operations. 
One way of doing this 
would be to write subroutines 
for each operation. 
A 


much nicer solution is to use the FORTRAN-80 
I/O in- 
structions 
(OPEN, 
CLOSE, 
READ, WRITE, 
PRINT, 


BACKSPACE, REWIND, 
and ENDFILE) 
to interface 


to user-written 
routines which implement these instruc- 


tions for the special device. 


This is possible because, for each open file in the system, 
the FORTRAN-80 
I/O system keeps a table connecting 


the unit number with the addresses of the routines that 
handle 
all operations 
on that 
unit. 
The 
I/O system 
allows the user to substitute his own device drivers into 
this table. 
To do this, the system designer 
codes a 


routine 
and labels 
it FQOLVL. This routine 
is then 


made known to the I/O system (i.e., declared PUBLIC). 
Whenever a file is first accessed (i.e., OPENED), the I/O 
system calls FQOLVL with a set of parameters, 
one of 
which is the file name referenced 
in the OPEN state- 


ment. The designer, in his code for FQOLVL, scans the 
file name to decide if this is one of the files for which he 
wishes to supply drivers. If so, he passes back a table of 
the addresses of the routines that will take care of the 
eight primitive file I/O capabilities 
(refer to the example 


following 
this paragraph 
and 
to the FORTRAN-80 
Compiler Operators Manual). 


DECLARE table 
(8) 
ADDRESS DATA ( 
.openShdlr, 
1* 
"ddress 
of 
OPEN routine 
*/ 
.closeShdlr, 
1* llddress 
of 
CLOSE routine 
•• / 


.readShdlr, 
/* 
address 
of 
READ routine 
/ 
.writeShdlr. 
1* 
address 
of 
WRITE 
routine 
*/ 
•. 


•back$hdlr. 
/* 
address 
of 
BACKSPACE 
routine 
I 


.mv2recShdlr, 
1* 
address 
of 
MV2REC routine 
*/ 


.rewlnd$hdlr, 
1* address 
of 
REWIND routine 
*/ 
.make$eof$hdlr 
1* 
address 
of 
END OF 
FILE 
routine 
*/ 
); 


DECLARE (ee turned$status. 
index) 
BYTE; 
DECLARE 
Cfile$ptr,bufSptr) 
ADDRESS; 
DECLARE buf 
8"SED 
bufSptr 
(1) 
B'iTE; 


DECLARE fileSname 
BASED fileSptr 
(1) 
B'iTE; 
DECLARE analog$in 
(.) 
B'iTE 
D"TA{':AI:'b 


/. 
set 
flag 
initially 
"FFH 
./ 


re tu rned$status=eFFH; 


/. 
if 
any 
character 
of 
flle$name 
does 
not 
cOllpare 
set 
flag-" 
./ 


DO Index-e 
TO ); 


IF 
filenamelindex) 
<> 
llnlllogSinlindex) 
THEN 
retu 
rned$s 
tatus-e; 
END; 


/. 
if 
flag-FFH 
pass 
back 
the 
addresses 
of 
the 
drivers 
./ 


IF 
returned$status-eFFH 
THEN 


CALL move (si 
ze (table) 
, • tllble, 
bu f$ptr> 
; 


RETURN returnedSstatus; 
END; 
/. 
of 
FQeLVL 
./ 


RMX/80™ 
Support 


When 
using 
the 
RMX/80 
Executive, 
the 
iSBC 
80 I 


FORTRAN-80 
RUN-TIME 
PACKAGE 
for 
RMX/80 


SYSTEMS 
can 
be used 
to provide 
a direct 
interface 
to 


standard 
RMX/80 
high 
level 
drivers, 
the 
Disk 
File 
System 
and 
the Terminal 
Handler. 
With 
the 
RMX/80 


Executive, 
users 
can 
code 
multiple, 
concurrently 


executing 
programs 
that 
perform 
formatted 
lIO to disk 


files 
and 
the 
console, 
as 
shown 
in 
the 
following 
example: 


C 
C -- OPEN 
disk file 
C 
OPEN 
(8,FILE 
= ':DO:TSTDTA.FIL',ACCESS 
= 


'SEQUENTIAL') 
C 
C -- perform 
tests 
C 


C 
C -- WRITE 
results 
to file for archival 
storage 
C 
WRITE(8,100) 
(RESULT 
(I),I= 
1,10) 
100 FORMAT(lOFI2.3) 
C 
C -- PRINT 
completion 
message 
on console 


C 
PRINT 
200 
200 FORMAT 
('TESTS 
COMPLETE') 


If 
it 
is necessary 
for 
a FORTRAN 
program 
in 
the 


RMX/80 
system 
to perform 
lIO to a device 
not handled 


by one of the high 
level drivers, 
any of the methods 
pre- 


viously 
described 
can 
be utilized 
to augment 
the 
lIO 


system. 


FORTRAN-80 
Math 
Capabilities 


The 
FORTRAN-80 
language 
supports 
four 
data 
types 
labelled 
INTEGER, 
REAL, 
LOGICAL, 
and 
CHARAC- 


TER. 
Also supported 
are 
various 
operators 
which 
can 


manipulate 
objects 
of various 
types. 
Both 
INTEGER 


(fixed 
point) 
and 
REAL 
(floating-point) 
objects 
can 
be 
manipulated 
by the add 
( +), subtract 
( - ), multiply 
(*), 
divide(/), 
and exponentiation 
(* *) operators. 
In addition, 
Integers 
can 
be operated 
on by the 
Boolean 
operators 


(e. g., .AND.,.OR.). 
In this 
case, 
the operations 
are per- 


formed 
bit-wise 
on the operands. 


All floating-point 
arithmetic 
operations 
are 
performed 


with 
algorithms 
that 
adhere 
to the Intel 
Floating-Point 


Standard' 
which 
allows 
for seven decimal 
digits 
of pre- 


cision. 
Whenever 
math 
operations 
are 
used, 
the 
user 


can 
make 
the 
decision 
to use 
a software 
package 
to 


implement 
the floating 
point 
support 
or to accelerate 
the 


execution 
of these operations 
(by as much 
as a factor 
of 


five or six) by install ing an iSBC 310 High-Speed 
Mathe- 


matics 
Unit 
and 
linking 
in special 
FORTRAN-310 


drivers. 
In 
either 
case, 
due 
to 
the 
adherence 
to 
the 


standard, 
the results 
of all calculations 
will be identical. 


In addition, 
the libraries 
have been designed 
to allow 
the 


switch 
to be made from software 
routines 
to a faster hard- 
ware solution 
with no code changes. 


Above 
and beyond 
the basic 
mathematical 
operators 
in 


FORTRAN-80, 
a large 
number 
of intrinsic 
functions 
are available. 
These 
functions 
provide 
services 
like type 
conversion, 
remaindering, 
and 
logarithmic 
and 
trigo- 


nometric 
calculation. 
Since 
the 
calculations 
involved 


in performing 
these 
high-level 
functions 
require 
the 


mathematical 
operators, 
they too can be accelerated 
by 


the inclusion 
of the 
iSBC 310 
board 
and 
its associated 


drivers. 


Error 
Handling 


The math 
processing 
system 
also provides 
flexible 
error 


handling. 
The 
user 
can 
choose 
to use either 
an 
Intel- 
supplied 
error 
handler 
or one 
of his own 
design. 
The 


capability 
also exists to change 
the active 
error 
handler 


dynamically 
in cases 
where 
different 
routines 
require 


different 
handlers. 
The default 
error 
handlers 
are named 


FQFERH. 
One exists 
in each 
of the arithmetic 
libraries 
(Figure 
3). This 
error 
handler 
will 
attempt 
to recover 


from an error 
by taking 
the most reasonable 
action 
(e. g., 


underflow 
error 
returns 
result = 0). If code 
is being 
run 
"stand-alone" 
or 
under 
the 
RMX/80 
executive 
the 


handlers 
in the math 
libraries 
should 
be used or the user 


should 
supply 
his own. 
Appendix 
B of the ISIS-II 
FOR- 
TRAN-SO 
Compiler Operator's Manual 
contains 
all of 


the information 
necessary 
to implement 
a custom 
error 


handler 
or to use the default 
routines. 


FPSOFT.LIB 
- Software 
package 
for "stand-alone" 


and ISIS-II systems 


FPHARD.LIB 
- iSBC 310 drivers 
for same 
*FPSFTX.LIB 
- Software 
package 
for RMX/80 
systems 


*FPHRDX.LIB 
- iSBC 310 drivers 
for iSBC 80/20, 


80/20-4 
and 80/30 
boards 
*FPHXIO.LIB 
- iSBC 310 drivers 
for iSBC 80/10 
and 


80/1 OA boards 
FPEF.LIB 
- Library 
of routines 
implementing 


intrinsic 
functions 


*Available 
in 
iSBC 
801 
FORTRAN-80 
RUN-TIME 


PACKAGE 
for RMX/80 
Systems. 


Figure 3. Available Math Libraries 


1•.Palmer, 
Joh." F., 'The 
Intel 
Standard 
rOT Floating-Point 
Arithmetic," 
Procudings 
of tht' 


flTst 
Intemohonal 
Computt>r 
Sofru..'ore 
and 
Applications 
Confer~nu 
(Chicago: IEEE Com- 


putcrSociel)'I.No 
••ember. 
1977, pp 107-112. 


An Automated 
Test Stand 


This example 
shows the steps taken 
to design and imple- 


ment 
an 
automated 
test stand. 
The 
hardware 
system 


must interface 
to a test fixture upon which 
test items can 


be mounted. 
Operator 
inputs 
and test outputs 
involve 
a 


300-baud 
hard 
copy terminal. 
The software 
to be devel- 
oped must allow 
an operator 
to invoke a variety 
of tests 
from 
the console 
and 
to receive 
some 
printed 
perfor- 


mance 
record 
for the object 
under 
test. In addition, 
the 
software 
must 
allow 
for tests to be added 
and deleted 
often, 
and 
each 
test 
must 
be 
allowed 
to obtain 
any 
number 
of parameters 
from the command 
line tail. 


After examining 
the problem 
definition 
and the decision 
making 
diagram 
presented 
earlier, 
it was decided 
that 


this application 
could 
be implemented 
with 
a simple 
sequential 
program. 


Since 
formatted 
I/O 
and 
mathematical 
calculations 


are involved, 
the FORTRAN-80 
language 
is well suited 
to 
be 
the 
main 
programming 
language. 
Also, 
some 
ASM-80 routines 
will come in handy 
for communicating 


with the console. 


An analysis 
of the I/O to be performed 
breaks 
down into 
two distinct 
types. Various 
inputs to and outputs 
from the 
text fixture 
will 
be 8-bit 
parallel 
transfers. 
These 
will 


likely go through 
the 8255A 
ports 
on the Single Board 
Computer. 
Port I/O will be used to handle 
this function. 


Interface 
with 
the 
operator 
requires 
READ'S 
AND 


WRITE's 
to the console device. The simplest 
way of per- 
forming 
this function 
is to use character 
strings 
as the 
target of READ and WRITE 
operations 
and coding small 


ASM-80 
routines 
to transfer 
these 
buffers 
from/to 
the 
console. 


A diagram 
of the test stand 
is shown 
in Figure 
4. The 


computer 
hardware 
necessary 
to solve this application 


includes 
a Single 
Board 
Computer 
(the 
iSBC 
80120 


board), 
a PROM 
memory 
module 
and 
an analog 
I/O 


board. 
Digital 
I/O with the test fixture 
is handled 
by the 


8255A ports on the Single Board 
Computer. 
The analog 


inputs on the test fixture 
come from the two D/A conver- 


ter channels 
on the iSBC 732 board. 


The software 
solution 
utilizes 
a very rudimentary 
com- 
mand 
line interpreter. 
The mainline 
routine 
gets a line 
of input 
and finds the first non-blank 
character. 
If this 
character 
is an 
alphabetic 
character, 
it is used 
in a 
computed 
GOTO 
statement 
to transfer 
control 
to one 
of a possible 
26 entry 
points. 
Tests 
may 
be added 
by 
choosing 
a key letter 
and inserting 
a label in the GOTO 


statement 
to transfer 
control 
to the new test routine. 
The 
command 
input 
line and the index in the line are stored 


in a common 
block so that any test routine 
can continue 
scanning 
the line for parameters 
or can reset the index 


and find out what 
key letter 
caused 
its invocation. 
The 
flow of the software 
is illustrated 
in Figure 
5. 


For 
the purpose 
of explanation, 
routines 
are shown 
to 


implement 
a "calculator 
mode" 
which 
allows the opera- 


tor to perform 
arithmetic 
from the console, 
and a logic 


transition 
tester which 
determines 
whether 
the object 
on 


the test fixture changes 
state at the proper 
voltages. 


COMPUTER 
/- 


- 
SYSTEM 
""r 


'\../ 


I 
DIA 
I 
I 
AID 
I 


--- 
TEST 
FIXTURE 


Code Description 


The 
following 
sections 
describe 
the program 
code 
for 


this application 
example. 
Fold-out 
code listings are con- 
tained 
in Appendix 
A. The 
circled 
reference 
letters 
in 


the text refer to the corresponding 
letters 
in the listings. 


The DRIVRS Module 


The module 
DRIVRS 
contains 
three 
primary 
routines. 


ST ART ® is located 
at 0 so that 
it is executed 
upon 


power 
up. This routine 
is responsible 
for programming 


the on-board 
hardware 
(8255A, 
825 1,8253), 
setting 
up 


the system 
stack, 
and 
calling 
the FORTRAN 
routine 


labeled 
MAINLN. 


The 
input 
routine 
BUFIN ® 
is 
called 
from 


FORTRAN 
routines 
with a character 
string 
as an argu- 


ment. 
Note that 
passing 
a string 
argument 
from 
FOR- 


TRAN 
results 
in the address 
and 
length 
of the string 


being 
sent as parameters. 
The string 
is filled with 
char- 


acters 
input 
from 
the console 
until 
a carriage 
return 
is 
encountered. 
A simple 
line-editing 
scheme 
is imple- 


mented 
allowing 
character 
deletion 
(RUBOUT), 
line de- 


letion (CONTROL-X), 
and echoing 
of the current 
buffer 


contents 
(CONTROL-R). 
Attempted 
entry 
of characters 


beyond 
the end of the string 
and RUBOUTS 
past the be- 


ginning 
cause the audible 
bell to sound. 


The output 
routine, 
BUFOUT 
© 
,also 
takes a char- 


acter 
string 
as an argument. 
The entire 
contents 
of the 
string 
are sent to the console 
unless a carriage 
return 
is 


encountered 
in the string. 
If a ca rriage 
return 
is the ter- 


minator, 
a line feed is output 
as well. If a CONTROL-S 
is entered 
at the 
console 
while 
output 
is in progress, 
output 
is suspended 
until a CONTROL-Q 
is typed. 


GET FIRST 
NON·BLANK 
CHARACTER 


GOTO 


PROPER 
ROUTINE 


The MAINLN 
Module 


The module 
MAINLN @ 
contains 
the mainline 
rou- 


tine that implements 
the command 
line interpreter. 
The 
statement 
IMPLICIT 
LOGICAL 
A-Z will 
cause 
most 


usages 
of undeclared 
variables 
to be reported 
as illegal 


mixed 
mode; 
the intent 
in writing 
these programs 
was 


to declare 
all variables, 
which 
is generally 
considered 


good 
programming 
practice, 
even 
though 
Fortran 


makes default 
assumptions 
about 
undeclared 
variables. 


The 
default 
handler 
is to be used for any errors 
that 


may occur 
while performing 
mathematical 
calculations. 


Also, the routines 
that perform 
the calculations 
must be 


initialized. 
Both of these 
operations 
are performed 
by 


the call to FQFSET ® .The call takes two arguments. 
The first argument 
is a two byte field specifying 
which 
error 
handler 
is to be used. 
If the low order 
bit of the 


high 
order 
byte 
is a one 
(e.g., 
100 hexadecimal), 
the 


math 
routines 
will 
call 
a user 
error 
handler 
whose 
address 
is given 
as the 
second 
parameter. 
If the 
low 


order 
bit is zero 
(as is the 
case 
in this 
example), 
the 


routines 
will 
use the 
default 
handler 
and 
ignore 
the 
second argument. 


A banner 
is output 
to the console 
by the sequence 
at 
® where 
a formatted 
WRITE 
is performed 
on 
an 


internal 
buffer 
(IMAGE) 
and 
then 
the external 
driver 


BUFOUT 
is called 
to output 
the buffer 
to the console. 


The 
variable 
CARRET 
is used 
to 
insert 
a 
carriage 


return 
into the string 
to be output. 
In order 
to allow 
in- 
dividual 
characters 
in the character 
string to be accessed, 


the 
EQUIVALENCE 
statement 
is 
used 
to 
cause 


LINBUF 
and 
IMAGE 
to 
occu~ 
the 
same 
memory 
space. 
The 
variable 
INDEX 
(QJ 
is used 
to 
scan 


through 
the input buffer. 


A call to BUFIN ® 
fetches 
the command 
line from 
the console. 
DBLANK 
is called CD 
to position 
INDEX 


to the first non-blank 
character. 
This character 
is con- 


verted to its integer 
representation, 
normalized 
to I and 
checked 
to see if it is a valid 
alphabetic 
character 
CD 
If the 
key letter 
is valid, 
the 
computed 
GOTO ® 


causes 
execution 
to branch 
to the 
correct 
point 
in a 


jump 
table @ . Note 
that 
A (add,) 
S (subtract), 
M 
(multiply), 
and D (divide) 
all branch 
to a single routine 


MATH, 
T (transition 
test) branches 
to a routine 
called 


TRANST 
and <Ill other 
key letters 
are trapped 
into line 


100. Any and all I/O errors 
cause the ERROR 
routine 
to 


be called. 


The DBLANK 
Module 


The DBLANK 
routine 
@ 
de-blanks 
the input 
line. If 


a carriage 
return 
is encountered, 
the 
operator 
is 


prompted 
for more input. 


The ERROR Module 


The ERROR 
routine ® 
prints 
out an error 
message, 


with the error number, 
to the console. 


The MATH Module 


In many 
of the tests, the human 
operator 
must 
supply 


numeric 
parameters. 
A calculator 
mode 
is supplied 
for 


the simple 
calculations 
that 
might 
be needed 
here. This 


mode is implemented 
through 
the MATH routine © 
Since anyone 
of four keyletters 
could 
have 
caused 
this 


routine 
to be invoked, 
MATH rescans 
the command 
line 


to obtain 
the key letter ® .Following 
this, 
two oper- 


ands 
are 
read 
in by calls 
to CONVRT 
@ 
and 
the 
operation 
requested 
is performed 
on them. 


The CONVRT 
Module 


Subroutine 
CONVRT ® is called 
from other 
routines 


to extract 
floating-point 
operands 
from 
the input 
line 
buffer. 
Characters 
are 
transferred 
into 
a temporary 
buffer ® 
until either 
a carriage 
return 
or a comma 
is 


encountered. 
The temporary 
buffer 
is then 
read 
under 


format 
control 
to obtain 
the returned 
value Q) 


The TRANST 
Module 


The 
item 
to be 
tested 
is composed 
of combinatorial 


logic as shown 
in Figure 
6. The transition 
test sets all 


inputs 
except 
one to a constant 
value. 
By varying 
the 
voltage 
at the remaining 
input, 
the 
transitions 
at the 


output 
can be checked. 
This test must be run while 
the 
+ SV power 
to the fixture 
is varied 
through 
a range 
of 


values. 
This 
testing 
is performed 
by 
the 
TRANST 


routine. 


Power 
is supplied 
to the test fixture 
through 
one of the 


two D/A channels 
on the iSBCTM732. Three of the input 


parameters 
specify 
the 
starting 
and 
stopping 
voltage 


values for Vcc and the increment 
to be added 
each step. 


The 
fourth 
parameter 
is the 
tolerance 
to be used 
to 


decide 
if the test passes or fails at each 
step. Once 
the 


test is running, 
the output 
voltage 
at @ 
is measured 


for inputs 
at CD of 0 and SV. The voltage 
input 
is then 


incremented 
from 
OV (using 
D/A 
channel 
I) until 
a 


transition 
is sensed 
in the output 
voltage 
at 
@ . At 


this poif\t, the input 
voltage 
at Q) 
is checked 
to see if 


it is within 
tolerance. 
The same process 
is then repeated 


with 
the voltage 
at 
CD 
going 
from 
+ SV downward. 


After 
the 
test 
is complete, 
a 
formatted 
report 
is 


generated 
containing 
the 
ambient 
temperature 


(measured 
through 
a temperature 
sensor) 
and 
the per- 


formance 
record 
for the item under 
test. 


ALL 
OTHER 


INPUTS 


HELD 
CONSTANT 


TEST STAND VO." 
COMMAND? 
M 34.&;78,"345.43 
34.67800 
* 


COMMAND? 
T 4.5,5.5,.2,5. 
TRANSITION 
TEST 
TOLERANCE= 
5.r% 


VCC 
HIGH TRANS 
LOW TRANS 
4.5 
00.81 
3.42 
4.7 
00.80 
3.44 
4.9 
00.80 
3.67 


5.1 
00.80 
3.71 


5.3 
00.80 
3.73 
5.5 
00.80 
3.74 


COMMAND? 


AMBIENT TEMPERATURE 
= 
HIGH 
LOW 
TEST 


4.43 
0.12 
PASSED 
4.67 
0.08 
PASSED 


4.88 
0.02 
PASSED 
4.93 
0.02 
PASSED 


4.98 
0.01 
PASSED 
4.99 
0.01 
PASSED 


An external 
routine @ , ADCIN, is called to input 


samples into the variable 
given as the first parameter 


from the channel 
given as the second parameter. 
The 
counts from the temperature 
sensor exhibit a logarith- 


mic curve, so the input is linearized using the equation 
shown. The routine DACOUT @ 
takes the first para- 


meter and outputs 
it to the channel 
specified by the 
second parameter. 
If no transition 
occurs when the test 


input is run through its entire range, the item is assumed 
non-functional, 
a mes~e 
is output, 
and control is re- 


turned to the console ® 


The ADCIN Module 


Subroutine 
ADCIN ® fetches samples from the AfD 


converter on the iSBC 732 board. The channel number 
is an input parameter 
and the data is the returned value. 


Of special note in this routine is the use of the FORTRAN 
common 
block to control 
a memory-mapped 
device. 
The master CPU communicates 
with the iSBC 732 by 


way of memory 
read and write commands 
instead of 


I/O commands. 
The primary 
reason for this is the fact 


that the 8080A IN and OUT instructions 
operate 
on 


only 8 bits at a time whereas SHLD and LHLD instruc- 
tions 
can 
manipulate 
16 
bit 
operands. 
This 
is 


convenient 
when working with 
12-bit inputs from the 
AfD 
and 
12 bit outputs 
to the D/A. 
In the code, a 


common block is created which has the same makeup as 
the memory mapped 
registers on the iSBC 732 board. 
The common block will be origined at the address of the 
iSBC 732 by the ISIS-II LOCATE program. 


The DACOUT Module 


Subroutine DACOUT <D makes use of the same com- 
mon block to output 
given values to a specified D/A 


channel. 


LINK and LOCATE 


The ISIS-II LINK command 
needed to pull together the 
individual 
pieces of this example is shown in Figure 8. 


After compilation, 
the object modules of all of the pre- 


viously 
described 
routines 
are placed 
in the library 
FRTMOD.LIB 
by the ISIS-II Library 
Managern ••.The 
LINK statement 
starts with the module DRIVRS.OBJ, 
which 
has one EXTERNAL 
reference, 
MAINLN. To 


satisfy this reference, 
MAINLN.OBJ 
is linked in from 
FRTMOD.LIB and its EXTERNAL references cause the 
inclusion of other modules. 


The LOCATE command 
shown in Figure 9 is used to 


assign absolute 
memory 
locations 
to the code in the 


LINKED modules. The common block labelled ADC is 
explicitly assigned to FFFOH so that it will correctly 
overlay 
the memory-mapped 
space of the iSBC 732 


board. The ORDER statement 
is used to tell the locator 


in what order the various segments should be placed in 
memory. 


LI~K 
:Fl:DRIVRS.OBJ, 
& 


:Fl:FRTMOD.LIB, 
& 


:FR:F8~RUN.LIB, 
& 


:FR:F80NIO.LIB, 
& 


:F~:F80ISS.LIB, 
& 
:F0:FPEF.LIB, 
& 
:F0:FPSOFT.LIB, 
& 


:F0:PLM80.LIB 
& 
TO 
:Fl:TSTND.LK0 
PRINT(:Fl:TSTND.LNK) 
MAP 


V. USING THE FORTRAN-80 RUN-TIME PACKAGE 
FOR RMXI80™ SYSTEMS 


The iSBC 801 package provides 1/0 interface and math 
routines for users who are coding RMX/80 applications 
in the FORTRAN-80 
language. 
In the following 
sec- 


tions, 
an overview 
of the 
RMX/80 
system 
will 
be 


presented along with a discussion of the use of the iSBC 
801 package. 
This overview 
is not intended 
to be ex- 
haustive. If the reader is unfamiliar 
with the RMX/80 


package, he should gain from this section enough un- 
derstanding 
to comprehend 
the concepts in the example 


presented. If the reader is planning on implementing 
an 


RMX/80 system, the RMX/80 references 
in the front- 
piece should be studied carefully. 


LOCATE 
:Fl:TSTND.LK0 
PRINT(:Fl:TSTND.LOC) 
MAP 
LINES 
SYMBOLS 
PUBLICS 
& 


ORDER(CODE 
DATA 
/LINE/ 
/ADe/) 
/ADC/(0FFF0H) 
STACKSIZE(0) 
CODE(0) 


Overview 
of the RMX/80™ Executive 


A large number 
of microcomputer 
applications 
require 


the 
ability 
to 
respond 
to 
events 
in 
real-time. 
The 
RMX/80 Executive 
provides 
the system software 
around 


which 
you can build 
a real-time 
multitasking 
applica- 
tion using Intel 
iSBC 80™ Single Board 
Computers. 
In 


addition, 
the RMX/80 
package 
provides 
the application 


designer 
with 
various 
high-level 
drivers 
(such 
as 
a 


terminal 
handler 
and a disk file system) which 
make 
it 


easier to develop 
sophisticated 
applications 
software. 


The RMX/80™ Model 


At this time, 
it is appropriate 
to discuss 
the 
RMX/80 


model, 
or in other 
words, 
the general 
concepts 
upon 


which 
the 
RMX/80 
Executive 
is 
built. 
Real-time 
systems, 
such as the RMX/80 
system, 
provide 
the cap- 


ability 
to control 
and respond 
to events occurring 
asyn- 


chronously 
in the 
physical 
world. 
To 
handle 
these 
events, 
the application 
is broken 
up into smaller 
semi- 


independent 
pieces, 
and each of these pieces is brought 
into action 
to handle 
the event for which 
it is intended. 
Each of these independent 
program 
units is a task. The 


RMX/80 
Executive 
manages 
the execution 
of these tasks 
in accordance 
with a user-designated 
priority 
scheme to 


insure 
that 
the highest-priority 
task 
in the system 
has 


control 
of the CPU. It is also necessary, 
in a system such 


as this, for these semi-independent 
program 
units (tasks) 


to communicate 
with 
each other. 
This communication 


may 
be 
for 
the 
purpose 
of 
synchronization, 
data 


passing, 
mutual 
exclusion 
or any 
other 
use that 
may 
arise. 
To 
facilitate 
inter-task 
communication, 
the 
RMX/80 
model 
incorporates 
the notion of messages 
and 


exchanges. 
A message is a data 
structure 
that 
can con- 
tain an arbitrary 
amount 
of information 
to be commun- 


icated from one task to another. 
An exchange is a "mail 


box" where tasks may send messages 
to be picked 
up by 
other 
tasks. 
The 
primary 
operations 
(primitives) 
that 


accomplish 
message 
transfers 
in the RMX/80 
system are 
RQSEND" 
and RQW AIT". 
Figure 
10 diagramatically 
shows the interaction 
of tasks, messages, 
and exchanges 
and 
introduces 
the symbolism 
used to represent 
these 
RMX/80 
concepts 
in the system design. 


Tasks 


Typically, 
a task will execute 
a section 
of code that per- 


forms 
some 
initialization 
and 
then 
enters 
an 
infinite 


loop performing 
some processing 
over 
and over 
again 


as shown in Figure 
II. 


Each task in the system has a priority 
associated 
with it. 


The RMX/80 
Executive 
uses this priority 
scheme 
to de- 
termine 
which 
ready 
task 
to run. 
The 
assignment 
of 


priorities 
to individual 
tasks is up to the system 
design- 


er, 
giving 
him 
the 
capability 
to tune 
his system 
by 
assuring 
timely execution 
of important 
functions. 


TASK0 


EXCHANGE 0 


TASKSENDINGMESSAGE 0--..0 


TASK 
RECEIVING 
MESSAGE 0-0 


C 
C -- DECLARATION 
OF VARIABLES 
HERE 
C 
C 
C -- INITIALIZE 
VARIABLES 
AND I/O PORTS 
C 


CALL OUTPUT 
(#OE8H,O) 


FLAG 
= I 
INDEX = I 
COUNT 
= 0 
SUM = 0 


C 
C -- ENTER 
INFINITE 
LOOP 


C 
I 
CALL INPUT(#OE9H,IV 
AL) 


GOTOI 
END 


Each 
RMX/80 
task also has its own stack, 
and there 
is 


no system stack. 
Whenever 
a task must give up the pro- 


cessor (e.g., must wait for the occurance 
of an interrupt) 


all of the information 
necessary 
to reawaken 
it at some 


future 
time 
without 
affecting 
the results 
of it's proces- 


sing is stored on its stack. 


Exchanges 


An exchange in the RMX/80 
system 
is a data 
structure 


that 
contains 
pointers 
to lists of tasks 
and 
messages. 


Whenever 
a message 
is sent to an exchange 
where 
there 


are no tasks waiting, 
it is added 
to the list of messages 
at 


that exchange 
until a task accepts 
it. Similarly, 
if a task 


waits at an exchange 
for a message 
and there 
is no mes- 


sage in the list, the task is added 
to the list of tasks wait- 


ing at that 
exchange. 
In both 
cases, the tasks and mes- 


sages are serviced 
on a first come, first served basis. Fig- 


ure 12 shows the possible 
states 
an exchange 
may be in 


at a given time. 
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Messages 


A message in the RMX/80 
system 
is a contiguous 
section 


of memory 
of an arbitrary 
length. 
Information 
can be 


stored 
in the 
message 
prior 
to 
it 
being 
sent 
to 
an 


exchange 
where 
it will be accepted 
by another 
task. 


Configuration 


The configuration 
module 
contains 
various 
tables 
and 
PUBLIC 
variables 
that 
are 
accessed 
by the system 
at 


start-up 
time. 
All of the necessary 
information 
on the 
tasks 
and 
exchanges 
to 
be 
created 
and 
the 
disk 
file 


system 
to be utilized 
are 
contained 
in this 
section 
of 
code. 
Configuration 
modules 
can 
be coded 
in either 


PUM or assembly 
language 
(for which 
there are macros 


included 
with the RMX/80 
product.) 


Memory 
Usage 


In systems 
using disk, it is necessary 
to ensure 
that 
cer- 


tain buffers 
used by the disk controller 
for Direct 
Mem- 


ory Access (DMA) are located 
in memory 
that 
is acces- 
sible to the disk controller. 
The buffers 
needed 
are allo- 
cated 
in a separate 
module 
called 
the controller addres- 


sable memory 
module. 
In the case of the iSBC 80/10, 


80/l0A, 
80/20, 
and 80/20-4 
boards, 
this module 
should 


be LOCATED 
before 
being 
included 
in the LINK state- 


ment to make sure that 
it does not contain 
any RAM on 


the 
CPU 
board 
itself 
(and, 
therefore, 
not 
controller- 
addressable). 
This 
restriction 
does not 
apply 
to iSBC 


80/30 
systems, 
since the iSBC 80/30 
board 
has a dual 


port bus allowing 
system access to on-board 
RAM. 


In the early 
1900's, 
the most 
popular 
type 
of sewage 


treatment 
system 
was 
known 
as a Sequencing 
Batch 


Reactor. 
It provided 
excellent 
effluent 
quality, 
but 
as 


populations 
grew, 
the amount 
of control 
necessary 
to 


operate 
the plant 
became 
too great 
for human 
opera- 


tors, and a new type of treatment 
system 
came 
into use. 


This new system 
did not require 
such accurate 
control, 


but it also did not perform 
as well. With the passage 
of 


stricter 
and 
stricter 
water 
quality 
laws, 
and 
with 
the 


advent 
of low-cost, 
high 
powered 
microcomputer 
con- 
trol systems, 
a serious 
look is being 
taken once again 
at 


Sequencing 
Batch Reactors. 


A diagram 
of the treatment 
system 
and its sensors 
and 


actuators 
is shown 
in Figure 
13. The 
system 
usually 


consists of three tanks, with each tank having 
individual 


influent 
and effluent 
valves, 
mixers and aeration 
equip- 


ment. 


At any given 
time, 
all influent 
is being 
routed 
to one 


tank. 
When 
this tank 
is filled, 
the influent 
is routed 
to 


one 
of the 
other 
two. 
The 
full 
tank 
is agitated 
and 
aerated 
until the bacteria 
in the tank 
digest the sewage 


to within 
given 
limits. 
At this time, 
the mixer 
and aer- 
ator are turned 
off and the contents 
settle. After a time, 


the supernatant 
fluid 
is drawn 
off leaving 
the layer 
of 
concentrated 
bacteria 
to digest the next batch. 


The computer 
control 
system 
necessary 
for controlling 


these reactors 
is shown 
in Figure 
14. The system 
is res- 


ponsible 
for monitoring 
the various 
sensors and contact 
closures, 
maintaining 
archives 
of system status, 
logging 


reports 
upon 
command, 
activating 
operator 
alarms, 


and performing 
on-line 
control 
of the batch 
cycle. 


Software 


An analysis 
of the functions 
that 
need to be performed 
by 
the 
software 
for 
this 
control 
system 
leads 
to 
a 
decision 
to use the RMX/80 
Executive. 
Timely 
response 
to multiple 
asynchronous 
events 
is the main 
thrust 
of 
this application. 
A breakdown 
of the individual 
func- 
tions in the system would be: 
• data collection - 
gathers 
inputs from the sensors and 


contact 
closures 
and stores them where other 
routines 


can 
access 
them. 
Also, 
converts 
data 
from 
analog 


counts to engineering 
units. 
• on-line 
control 
- 
based 
on 
current 
sensor 
inputs 


determines 
whether 
aeration, 
agitation, 
discharge 


and fill should be on or off. 
• alarm 
scanning 
- 
compares 
current 
status 
values 


with 
setpoints 
and sets operator 
alarms 
if conditions 


are out of tolerance 
when effl uent is on. 
• data logging - 
once every five minutes 
logs current 


system status into a disk file record. 
, 


• real-time 
clock - 
maintains 
day, 
month, 
year, 
and 
time of day. 
. 


• operator console handler - 
monitors 
operator 
con- 


sole to detect 
operator 
commands 
for time 
and 
set- 
point changes, 
report 
generation, 
alarm 
clearing, 
etc. 
• report generation 
- 
upon 
operator 
command, 
for- 


mats either the file corresponding 
to yesterday's 
oper- 


ation or today's 
operation 
to the current 
moment. 


Each 
of these functions 
must be studied 
independently 


before the decision 
on which 
language 
to use for each is 


made. 
The 
functions 
concerned 
with 
data 
collection, 


on-line 
control, 
and alarm 
scanning 
will be concerned 
with mathematical 
calculations. 
The functions 
concern- 
ed with 
data 
logging 
and 
report 
generation 
will have 


need of formatted 
disk and console 
I/O. These 
routines 


will thus be coded in the FORTRAN-80 
language. 


As was mentioned 
earlier, 
the PUM-80 
language 
is a 


systems 
programming 
language. 
This 
means 
that 
it is 


optimized 
to deal with the concepts 
embodied 
in a high- 


level system 
such as the RMX/80 
system. 
The program 


code that 
implements 
the real-time 
clock 
and operator 


console 
handler 
will 
be 
written 
in 
the 
PUM-80 


language. 
In addition, 
various 
PUM-80 
support 
routines 


will be written 
to be called 
on by one or more 
of the 


FORTRAN-80 
routines. 
The purpose 
of these 
routines 


will be explained 
as they come up in the code descrip- 


tions following. 
Hardware 


The hardware 
used to implement 
this 
control 
system 


must perform 
the following 
functions: 
• inputting 
analog 
samples 
from the various 
sensors 


• outputting 
analog 
values to the pneumatic 
posilioners 


• inputting 
digital 
values from the contact 
closures 
and 


operator 
console 
• outputting 
digital 
values 
to the operator 
console 
and 


alarm 
panel 
• storing 
and retrieving 
data from diskette files 


~ 


CONTACT 
CLOSU~ 
r=cJ 


I I I I I 00 
,I ....,1/,1, 
,1",1/ 
-0--0--0- 
-0--0- 
....1' /1' 
/1' 
/1' 
/1' 


The 
hardware 
configuration 
chosen 
includes 
an 
iSBC 


80/30 
Single 
Board 
Computer, 
an iSBC 732 Combina- 
tion 
Analog 
Input/Output 
Board, 
a combination 
of 


PROM 
and 
RAM 
memory 
modules, 
and 
an 
iSBC 
20 I 


Diskette 
Controller. 


There 
are various 
types 
of I/O devices 
in this system 
and 


each 
will 
require 
different 
FORTRAN-80 
I/O support. 


The 
terminal 
and 
disk 
devices 
are 
supported 
through 


the 
iSBC 80 I run-time 
package 
and 
the 
RMX/80 
high 
level 
drivers. 
Communications 
with 
the 
A/D and 
D/A 


converters 
is 
accomplished 
using 
internal 
buffer 


formatting 
in 
conjunction 
with 
the 
RMX/80 
Analog 


Handlers. 
Finally, 
port 
I/O is used for the digital 
inputs 
and outputs. 


The 
next step in the design 
is to assign 
the system 
soft- 


ware 
functions 
to individual 
tasks 
in a manner 
that 
will 


allow 
for their 
parallel 
execution. 
The 
following 
tasks 
will be created 
to handle 
this application: 


• STSINP 
- 
status 
input 
and unit conversion 


• CNTROL 
- 
on-line 
control 
• SCAN and TIMERS 
- 
alarm 
scanning 
and data 


logging 


• TIMER 
and TIMUPD 
- 
real-time 
clock 
• CONSOL 
- 
operator 
console 
handler 
• REPORT 
- 
report 
generation 


Figure 
IS shows 
the 
interaction 
of these 
tasks 
in the 


RMX/80 
system. 


System 
Considerations 


At this point, 
let us consider 
some of the mechanisms 
this 


system 
will 
require 
to synchronize 
and 
co-ordinate 
the 


tasks 
we have 
created. 
Status 
and 
setpoint 
information 


will 
be stored 
in FORTRAN 
common 
blocks. 
This 
will 
allow 
the 
STSINP, 
CNTROL, 
SCAN, 
CONSOL, 
and 


TIMUPD 
tasks 
access 
to the STATUS 
information, 
and 


the CNTROL, 
SCAN, 
and 
CONSOL 
tasks 
access 
to the 


SETPNT 
information. 
Once 
per five minutes, 
SCAN will 


be notified 
through 
a flag 
byte 
(MINSUP) 
that 
he is to 


write 
the current 
system 
status 
to the file TODA YS.RPT. 


Upon command 
from the operator, 
REPORT 
will need to 


read these files to generate 
reports. 


Since the RMX/80 
system 
is designed 
to handle 
asynchro- 
nous events, 
it is quite 
possible 
for any of the tasks 
to be 


pre-empted 
at any point 
in their 
execution 
(e.g., an inter- 
rupt 
occurs 
or a higher 
priority 
task becomes 
ready 
to 


run). 
Thus, 
the 
SCAN 
task 
may 
be 
in the 
process 
of 


reading 
the last byte of a four-byte 
REAL 
integer 
when 
STSINP 
pre-empts 
the SCAN task and writes 
new infor- 
mation 
into 
the 
STATUS 
common 
block, 
thus 
inval- 


idating 
the current 
SCAN operation. 
In another 
instance, 


REPORT 
may be in the process 
of fetching 
a disk record 
when 
SCAN 
attempts 
to write 
to the 
file. 
For 
these 


reasons, 
and more, 
it is necessary 
to implement 
some sort 
of synchronization 
mechanism 
in this system. 
We will 
insure 
that 
at most, 
one task 
has access 
to the common 
blocks 
and 
disk 
records 
by 
using 
a technique 
called 


mutual exclusion. In the RMX/80 
system, 
this is accom- 


H 
"'0'" 
Y 
VARIABLE 
B0 


plished by creating 
an exchange 
for each shared 
resource 
and 
initially 
sending 
one 
message 
to 
it. 
Any 
task 
requiring 
access to the resource 
first waits at the associ- 


ated exchange 
for the key message. 
If a message 
is at the 


exchange, 
the task 
obtains 
the message 
and 
continues 
running 
until finished 
and then sends the message 
back. 


If another 
task waits at the exchange 
while the first is pro- 


cessing, 
it will stop execution 
until the first task finishes 


and returns 
the message. 


Code Descriptions 


What 
follows 
is a description 
of the code used to imple- 


ment 
most of the tasks discussed. 
Appendix 
B contains 
fold-out 
code listings with circled 
reference 
letters. In the 
description, 
sections 
of the code will be called out using 


circled 
letters 
that 
correspond 
to 
symbols 
in 
the 
appendix. 


The Semmod 
Module 


Two PL/M routines 
called LOCK and UNLOCK 
perform 
the mutual 
exclusion 
operation 
discussed 
earlier. 
There 


are three 
exchanges 
used for the purpose 
of exclusion: 


STSLOK, 
SETLOK, 
and DSKLOK. 
They govern 
access 


to the STATUS 
common 
block, 
the SETPNT 
common 
block and the disk file respectively. 
The LOCK procedure 


@ 
takes one parameter, 
a number 
representing 
one of 
the three exchanges, 
and performs 
a wait 
at the appro- 
priate exchange. 
Note the use of based variables 
to access 


the parameter. 
This is necessary 
since FORTRAN 
passes 


parameters 
by reference 
(address) 
rather 
than 
by value. 


The 
UNLOCK 
procedure 
® 
takes 
the same 
para- 


meter 
and 
sends 
the single 
key (message) 
back 
to the 


appropriate 
exchange. 


These routines are written in the PL/M language because 
they must deal directly with a few system concepts that 
the FORTRAN-80 language does not. In particular, 
the 
RQW AIT routine returns to the caller the address of the 
message received from the exchange. In either the PL/M- 
80 or ASM-80 languages 
this address can be used to 
access 
the 
information 
in 
the 
message 
received. 
FORTRAN-80 routines do not have the capability to use 
address 
values 
to access 
data 
outside 
of their 
own 
module. 


The STSINP Module 


The module 
STSINP © 
performs 
the function 
of 
updating 
the STATUS common 
block with new data 
from the sensors that has been converted to engineering 
units. 
STSINP 
initializes 
the 
FORTRAN-80 
math 


routines @ 
and directs them to use the default error 
handler. STSINP then calls INIT$IO ® 
which initial- 


izes the message that will be used to communicate 
with 


the 
RMX/80 
Analog 
Input 
Handler. 
The 
call 
to 
SMPLIN ® 
fills the buffer with analog samples from 


the sensors, and the following 
DO loop right-justifies 
the 12-bit samples in the 16 bit field © .STSINP now 
waits for access to the STATUS block, 
converts 
the 
samples, stores them, inputs and stores the values of the 
contact closures and calls UNLOCK ® .The function 
performed 
by STSINP is not a continuous 
function. 


Update 
of the status 
information 
once per second is 
sufficient. The call to WAIT CD 
delays execution for 


one second. 


LINK 


LENGTH 
I 


TYPE 
I 


HOME EXCHANGE 


RESPONSE EXCHANGE 


STATUS 


BASE REGISTER POINTER 


ARRAY1 POINTER 


ARRAY2 POINTER 


COUNT 


Figure 16. Request Message for Sequential Channel In· 
put with Single Gain 


TheANALOG$IO$MOD 
Module 


In the module labelled ANALOG$IO$MOD, 
the declar- 
ation of READ$MSG (]) 
uses the predefined LITERAL 
called AI$MSG. This LITERAL is one of many in the 
RMX/80 package that can be used to attach meaningful 
symbolic names to PL/M data structures. In this instance, 
AI$MSG defines the fields of a standard 
analog input 
request message. Figure 16 is a diagram of the individual 


fields of the request message. The definition and usage of 
each of these fields is described 
in the RMXI80 
User's 
Guide. The 
procedure 
INIT$IO ® 
is called 
by 


STSINP. It simply initializes 
the analog 
input request 


message and returns. Note the assignment operation 
in 


line 29. The RESPONSE$EXCHANGE 
field of the 


request message must contain the address of the exchange 
where the RMX/80 Analog Handler should send the res- 
ponse to the request (see Figure 17 for a diagram 
of the 


request-response mechanism). In the PL/M language, this 
address is assigned using a location reference - a variable 
name preceded by a period, which stands for the address 
of the variable. FORTRAN-80 routines lack the ability to 
refer to the address of variables. 


The procedure SMPLIN @ 
fills in a buffer, given as an 
input parameter, 
with analog samples from sequential 
channels on the A/D. Note the mechanism used to handle 
the passing of a FORTRAN string as a parameter. 
For 
every string in the parameter 
list, FORTRAN passes the 


starting 
address of the string followed by its length in 


bytes. 


The SCANModule 


The SCAN task is responsible for operator alarms and 
data logging. The EQUIVALENCE statements 
@ 


cause the STATUS common block to be overlaid by a 
character string, as illustrated in Figure 18. This allows 
for a compact file on disk of numerical data which can 
be broken out later for report generation. 


After initialization, 
SCAN waits for access to both the 


STATUSand SETPNT common blocks. Operator alarms 
need to be set only if a parameter is out of specification 
and the effluent pump is on ® .After performing the 
scan, the variable MINsUP is checked @ 
to see if a 


report should be logged. If so, SCAN~ins 
access to the 


disk file and writes a single record \.V . All locks are 
now released, a one-second delay is counted out, and 
SCAN repeats the whole process. Normally, any errors 
that occur during the execution of I/O statements in the 
run-time package cause a message to be output on the 
console and the offending task to be suspended. Since this 
action is often undesirable, 
it is wise to handle one's 


errors programatically 
@ 


The MIN$5$MOD Module 


The module MIN$s$MOD 
contains two procedures. 


Both routines make use of the timed wait facility in the 
RMX/80 system. Any time a task calls RQWAIT to wait 
for a message at an exchange, an optional time limit (in 
SOmsec. intervals) can be specified. This is useful if the 
designer does not wish the task to be hung up forever if 
a message is never sent to that exchange. This mechan- 
ism can also be used to implement a timed wait if an 
exchange is specified to which no one will ever send a 
message. WAIT ® 
delays execution of the calling 


task for one second. 
TIMERS @ 
waits 
for five 


minutes and then sets the variable MINsUP to signal 
SCANto log a disk record of current status. 


The REPORT Module 


The system console contains two buttons, one each for 
requests for printouts of today's and yesterday's status 
reports. Whenever one of these two buttons ispushed, the 
CONSOL 
task 
sends 
a message 
to the 
PRTREQ 


exchange with the TYPE field indicating which file to 
print. REPORT accepts these messages, checks the TYPE 
field G) , and calls the FORTRAN subroutine PRINT 
with the appropriate 
filename as a parameter. It then 


returns the request message to its sender via the response 
exchange field and waits for another request. Figure 19is 
an example of the report generated by this system. 


The PRINT Module 


The PRINT subroutine 
will read in the compressed 


records written by SCANand use the same set of EQUIV- 
ALENcE statements to break out the numerical data so 


that 
it can be formatted 
for printout. 
If the type 


field ® 
indicates that today's file is being accessed, 


PRINT obtains the key to the DSKLOK exchange since 
SCANmay disturb output operations if it attempts to log 
a new record. If yesterday's file isbeing accessed, the lock 
is not necessary, since no other task will be accessing this 
file. Once the lock isobtained, a record isread, the digital 
value of the contact closure status is converted to a more 
readable form @ (ON or OFF), and the status line is 
formatted 
and printed. 
Since the SCAN task has an 


important function (operator alarms), we do not wish to 
hold it up for long if it happens to want to log a new status 
record. For this reason, PRINT relinquishes access to the 
file after every tenth record to allow SCAN to log its 
record and continue on. The rest of the code ® checks 
for end of file indications and returns when printing is 
finished. 


The INITMOD Module 


Last in order (but first in execution) is the INIT proce- 
dure. It is called from the TIMER task, which is the 
highest-priority task in the system (and thus, will be the 
first to execute after start-up). INIT's role in life is to call 
FQOGO ® 
to initialize the FORTRAN I/O system, 


send one message to each of the lock exchanges (il ,and 
initialize the operator 
alarm panel ® . The call to 


FQOGO isa requirement for an RMX/80 system in which 
any FORTRAN-80 code that makes use of the iSBC 801 
package isto be executed. The call must be made prior to 
the execution of any FORTRAN-80 I/O or math instruc- 
tions. Also, the call to FQOGO should only be made 
once. 


VOLUME 
DISSOLVED 
OXYGEN 


(CU.JIIl) 
ee) 
(MGjML) 


9/19/18 
8: 
5: 
iii 
6.1 
2012.32 
25.4890 
12.3400 


9/19/78 
8:19:" 
6.2 
2614.08 
25.40liHI 
12.54U 


SUSPENDED 
PHOSPHATE 
INFLUENT 
EFFLUENT 
TURbID 
AIR 
015 
MIX 
HU' 


SOL.IOS 
CONe 
now 
now 


(MC/JIlL) 
(Me/fill) 
(MG/ML) 
(MG/I'lL) 
, 


16.1'987 
56.9808 
112,099 
0.eee 
74.56 
ON on' 
ON 
ON 


19.3943 
61.4300 
119.340 
0.00086.43 
ON OFF 
ON 
ON 


SYSTEMGENERAnON 
Configuration Module 


Now that all ofthe code for the individual tasks iswritten, 
it is time to generate the tables that give the RMX/80 
Executive the information it needs to configure all of the 
tasks and exchanges. Assembly language macros are in- 
cluded in the RMX/80 product to help make building 
the configuration 
module 
a little easier. 
After the 


counters have been initialized, the STD macro is invoked 
several times to define Static Task Descriptors for the 
tasks in the system. Of special note are the last two entries 
8 .Any task that uses the FORTRAN I/O system 


must allocate approximately 
800 bytes of stack. This 


extra stack space is needed to save information on the 


current 
I/O operations. 
Also, any task 
performing 


floating 
point calculations 
with the software package 
needs to append an extra IS bytes to its Task Descriptor 
as a workspace 
area. If the iSBC 310 drivers are used 


this need be only 13 bytes long. 'This last field is de- 
fined by passing a value of 13 or IS to the optional 
parameter, 
TDXTRA, in the STD macro. The routines in 


the FORTRAN-SO Run-Time Package 
require one ex- 


change, FQOLOK, which is allocated 
using the XCH 


macro @ ,and adde~ 
the Initial Exchange Table 
by the PUBXCH macro 0 


Controller Addressable Memory Module 


The CAMMOD module @ 
allocates the blocks of 


memory 
needed 
by the RMX/SO Disk File 
System. 


Specific details on the contents of this module can be 
found in the RMXIBO 
User's Guide. 


LINK 


Figure 20 shows the ISIS-II LINK command used to bind 
all of the individual modules together with the RMX/SO 
libraries 
needed to implement 
this application. 
The 
FORTRAN-SO VO interface 
routines are found in the 


library FSORMX.LIB which ispart of the iSBC SOl pack- 
age. the library 
FPSFTX.LIB 
contains 
the software 
floating point package. If it is desired to accelerate 
the 
execution of the mathematical 
operations in this system, 
the iSBC 310 board 
can be included 
and the library 
changed to FPHRDX.LIB for iSBC SO/20, S0I20-4, and 
SO/30 systems or FPHXIO.LIB 
for iSBC SO/IO and 
SO/IOAsystems. 


The RMX/SO extensions included are the Disk File Sys- 
tem, the Analog Handlers, 
and the Minimal Terminal 


Handler. 


LOCATE 


After the Link has been finished, the command shown in 
Figure 21 isused to invoke the ISIS-II LOCATE program. 
The ORDER statement sets the proper order for all of the 


different segments and common 
blocks. The common 


blocks 
themselves 
are allocated 
as fixed blocks 
of 


memory to make possible their shared usage by PUM 
routines 
using the AT attribute. 
This mechanism 
is 


discussed 
in greater 
detail 
in AP-44, 
"How 
to use 


FORTRAN With Other Intel Languages". 


The purpose of this application 
note has been to describe 


the design process used to decide what operating system 
support to use, what language to code programs 
in, what 


hardware 
to use and what type of VO to use to solve a 


given application 
problem. The specific application 
ex- 
amples 
presented 
have 
keyed 
on 
the 
use of 
the 


FORTRAN-SO language. 


The lesson that has been learned is that proper design 
techniques result in the use of the right tool for every job. 
With a complete set of programming 
languages, 
each 
optimized 
for a specific 
use, a powerful 
real-time 


executive, 
and a complete 
line of flexible hardware 


products, 
complicated 
applications 
become 
easy to 


solve. 


LINK 
:F'l':RMxfl3e.LlB(START), 
6- 
: f 1: x 2C FG. 
OBJ, 
Eo 


: Fl: 
RPTMOD. 
OBJ, 
I> 


:Fl:fRTMOD.LIB, 
&- 


:F]:INITMD.OBJ, 
f. 


:Fe:FseRUN.LIR, 
&- 


:FC':FePRMX.L1B, 
&- 


:F0:FPEF.LIB, 
f. 


:F'C:FPSFTX.LIB, 
& 
:F0:SYSTEM.LIB, 
0- 


: fr: 
orSOlR. 
LIB 
(DIRECTORY, 
DELETF:, 
REJIlA"lE, 
SEEK), 
& 


:F0:DI083fl.LIB, 
I> 
:Fr:DFSUNH.LIB, 
& 
:Fl 
:CAM.OBJ, 
Eo 


: Fl 
: PLMMOD. 
LIB, 


:FPI:AIHDLR.LIB, 
:F91:AOHDLR.L.IB, 
:F0:MTI830.LIB, 
:F0:MT0830.LIB, 
:F"-:RMX830.LIB, 
:HI:UNRSLV.LIB, 
(" 


:FP:PLMfH',.LIB 
TO 
;F']:SEWAGE.LKPI 
PRINT(:Fl:SE'",'AGF.:.LNK) 
MAP 


LOCATE 
:Fl:SEWAGE~LK~ 
PRINT(:Fl:SEWAGE.LOC) 
MAP 
& 


CODE(0) 
STACKSIZE(0) 
LINES 
SYMBOLS 
PUBLICS 
& 


ORDER(CODE 
DATA 
/LSTREC/ 
/STATUS/ 
/SETPNT/ 
/MINS/) 
/STATUS/(FFASH) 
& 
/SETPNT/(FFDEH) 
/MINS/(FFEEH) 
/LSTREC/(FFA3H) 


APPENDIX 
A 
CODE LISTINGS 


0000 
000.0. 
001B 
001B 
007F 
0008 
0013 
0011 
0007 
0012 
00ED 
00EC 
0001 
0002 
0040 
004E 
0027 
00B6 
0092 
BBDE 
ISDF 
00EB 
0080 
00E0 


1 NAME 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 


CONSOLE 
1/0 
ROUTINES 
FOR 
FORTRAN-iSBC 
SYSTEM. 
START 
INITIALIZES 
THE 
HARDWARE 
AND 
CALLS 
THE 


FORTRAN 
ROUTINE 
MAINLN. 
BUFOUT 
ACCEPTS 
TWO 


PARAMETERS 
FROM 
THE 
CALLING 
FORTRAN 
ROUTINE 


(ACTUALLY 
ONE 
FROM 
THE 
ROUTINE 
SINCE 
PASSING 


A 
STRING 
ARGUMENT 
FROM 
FORTRAN 
RESULTS 
IN 
THE 
ADDRESS 
AND 
LENGTH 
OF 
THE 
STRING 
BEING 
SENT) 
AND 
OUTPUTS 
THE 
STRING 
TO 
THE 
USART 
ON 
THE 
P0/20. 
BUFIN 
TAKES 
THE 
SAME 
TWO 


ARGUMENTS 
AND 
FILLS 
IN 
THE 
BUFFER 
WITH 


CHARACTERS 
UNTIL 
<CR> 
IS 
ENCOUNTERED. 
LINE 


EDITING 
IS 
PROVIDED 
TO 
THE 
EXTENT 
THAT 
RUBOUT 
DELETES 
A 
CHARACTER 
AND 
ECHOES 
IT, 


CONTROL-X 
DELETES 
THE 
BUFFER 
AND 
STARTS 
OVER, 
AND 
CONTROL-R 
PRINTS 
THE 
BUFFER 
CONTENTS. 


BUFOUT 
CALLS 
THE 
ROUTINE 
CHKIO 
TO 
DETERMINE 


IF 
A 
CNTL-S 
HAS 
BEEN 
ENTERED 
TO 
CAUSE 
A 
PAUSE 


IN 
THE 
OUTPUT. 
IF 
ENCOUNTERED 
THE 
ROUTINE 


WAITS 
UNTIL 
A 
MATCHING 
CNTL-Q 
IS 
ENTERED. 


CR 
LF 
ESC 
CNTLX 
RUBOUT 
BS 
CNTLS 
CNTLQ 
BELL 
CNTLR 
CSTS 
CDATA 
TXRDY 
RXRDY 
RESET 
USMODE 
USCMND 
TIMCMD 
CMD55 
CNTR2 
TIMCP 
PR8255 
STKSIZ 
BDFCTR 


0DH 
BAH 
IBH 
18H 
07FH 


08H 
13H 
IlH 
07H 
12H 
0EDH 
0ECH 
01H 
02H 
40H 
~EH 
27H 
0B6H 
92H 
0DEH 
0DFH 
0EBH 
128 
224 


;ASCII 
COOE 
FOR 
CARRIAGE 
RET. 


jASCII 
CODE 
FOR 
LINE 
FEED 
;ASCII 
COOE 
FOR 
ESCAPE 


;ASCII 
CODE 
FOR 
CONTROL-X 


;ASCII 
CODE 
FOR 
RUBOUT 


;ASCrI 
CODE 
FOR 
BACKSPACE 


;ASCII 
CODE 
FOR 
CONTROL-S 


;ASCII 
CODE 
FOR 
CONTROL-Q 


iASCII 
CODE 
FOR 
BELL 
;ASCII 
CODE 
FOR 
CONTROL-R 


;USART 
COMMAND/STATUS 
PORT 
ADD 


;USART 
DATA 
PORT 
AODRESS 


;MASK 
FOR 
TRANSMITTER 
READY 


;MASK 
FOR 
RECEIVER 
READY 


iUSART 
RESET 
COMMAND 


iUSART 
MODE 
WORD 
iUSART 
COMMAND 
WORD 
iBAUD 
RATE 
CNTR 
COMMAND 
WORD 


;8255 
COMMAND 
WORD 


iBAUD 
RATE 
CNTR 
PORT 
ADDRESS 


;TIMER 
CONTROL 
PORT 
ADDRESS 


;8255 
COMMAND 
PORT 
ADORESS 


;STACK 
SIZE 
;BAUD 
RATE 
FACTOH(COUNT 
VALUE) 


LOC 
OBJ 
SEQ 
SOURCE 
STATEMENT 


53 
OSEG 
008r 
54 
FRTSTK: 
OS 
$TKSIZ 
55 
56 
LOCAL 
DATA 
STORAGE 
57 
; 


e~02 
58 
BUFPTR: 
OS 
;BUFFER 
POINTER 
STORAGE 
59 
CSEG 
60 
61 
START--STARTUP 
ROUTINE 
PROGRAMS 
THE 
USART 


62 
AND 
TIMER 
THEN 
CALLS 
THE 
FORTRAN 


63 
ROUTINE. 
IF 
THE 
FORTRAN 
ROUTINE 


64 
RETURNS 
START 
SIMPLY 
STARTS 
OVER. 


65 
66 
EXTRN 
MAINLN 


e~e0 
317F00 
0 
67 
START' 
LXI 
SP,FRTSTK+STKSIZ-l 
;SET 
STACK 
POINTER 


0003 
AF 
68 
XRA 
A 
;ZERO 
ACCUMULATOR 


0004 
D3ED 
69 
OUT 
CSTS 
;BRING 
USART 
TO 
KNOWN 
STATE 
0006 
03EO 
70 
OUT 
CSTS 
;BY 
SENDING 
FOUR 
NULLS 
00ee 
03EO 
71 
OUT 
CSTS 
000.0.D3ED 
72 ® 


OUT 
CSTS 
H0C 
3E~ 0 
73 
MVI 
A,RESET 
;RESET 
USART 


000E 
03ED 
74 
OUT 
CSTS 
0010 
3E4E 
75 
MVI 
A,USMODE 
;SEND 
USART 
MODE 
WORD 


0~12 
03EO 
76 
OUT 
CSTS 
0014 
3E27 
77 
MVI 
A,USCMND 
;SEND 
USART 
COMMAND 


2-52 
AFN-01931A 


~016 
D3ED 
0~18 
3EB6 
001A 
D3DF 


0~lC 
3EEC 
001E 
D3DE 


eC2C 
3Ee~ 


~022 
D3DE 
0~24 
3E92 
~~26 
D3EB 
~e28 
CD0000 
0e2B 
C30000 


002E 
ES 
002F 
FS 
0030 
CS 
~031 
60 
0~32 
69 
0033 
228000 
0036 
1600 


~039 
CDE2e~ 
003C 
FE7F 
003E 
C247~0 
0e41 
CD9~e~ 


0047 
FE18 
0049 
CAA200 
004C 
FE12 
004E 
CAF900 
00S1 
10 
0052 
C26300 
0ess 
FE0D 


e0S7 
CA630~ 
00SA 
1C 
00SB 
~E07 
0050 
CDB4 e0 
0~60 
C3390e 


~e63 4F 
0864 
CDB488 
e067 
71 
~068 
23 
0069 
14 
006A 
3E0D 
0e6C 
B9 
0060 
C2390~ 
e878 
01 
0871 
Cl 


0872 
Fl 
8073 
El 
0~74 
C9 


8075 
ES 
0076 
FS 
0077 
60 
0e78 
69 
0079 
COCD00 
887C 
4E 
0070 
CDB4~0 
0080 
3E0D 
0082 
B9 
0083 
CA8De0 
0086 
23 
0087 
1B 
0888 
7A 
0089 
B3 
U8A 
C2798~ 
0080 
Fl 
088E 
El 
008F 
C9 


SEQ 


1~8 
109 
110 
111 
112 
113 
114 
115 
116 
117 
118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 
155 
156 
157 
158 
159 
160 
161 
162 


OUT 
MVI 
OUT 
MVI 
OUT 
MVI 
OUT 
MVI 
OUT 
CALL 
JMP 


CSTS 
A,TIMCMD 
;SEND 
COMMAND 
WORD 


TIMCP 
A,LOW(BDFCTR) 
,SEND 
LOW 
ORDER 
BYTE 


CNTR2 
,OF 
COUNTER 
VALUE 
A,HIGH(BDFCTR) 
;SEND 
HIGH 
BYTE 
OF 


CNTR2 
,COUNTER 
VALUE 


A,CMDSS 
;8255 
COMMAND 
WORD 


PR82SS 
;PROGRAM 
8255 
MAINLN 
,CALL 
FORTRAN 
ROUTINE 


START 
,IF 
ROUTINE 
RETURNS 
START 
OVER 


PUBLIC 


BUFIN:~ 
PUSH 
PUSH 
PUSH 
MOV 
MOV 
SHLD 
MVI 


PUSH 


GETCHR: 


® 


H 
PSW 


B 
H,B 
L,C 
BUFPTR 
0,0 


o 


CALL 
CPI 
JNZ 
CALL 


CI 
RUB OUT 
BUFes 
DLTCHR 


;SAVE 
HL 
PAIR 
,SAVE 
PSW 


;SAVE 
BC 
;GET 
BUFFER 
POINTER 
TO 
HL 


; 
iSAVE 
IT 


,ZERO 
TO 
t 
CHARACTERS 
COUNTER 
;NOTE: 
STRING 
LENGTH 
<-255 


;SAVE 
COUNTERS 


;GET 
CHARACTER 


iRUBOUT? 
;NO,CONTINUE 
;YES,DELETE 
LAST 
CHARACTER 


© 


CPI 
JZ 
CPI 
JZ 
OCR 
JNZ 
CPI 
JZ 
INR 
MVI 
CALL 
JMP 


CNTLX 
DLTLIN 
CNTLR 
PRTBUF 


E 
BUF10 
CR 
BUFl8 


E 
C,BELL 
ECHO 
GETCHR 


iCONTROL-X? 
;YES,DELETE 
BUFFER 
,CONTROL-R? 
;YES,PRINT 
BUFFER 
jDECREMENT 
SPACE 
LEF1' 
COUNTER 
;CONTINUE 
IF 
COUNTER 
> 
0 
,IF 
THIS 
END 
OF 
LINE 
ALL 
IS 
OK 


iMOVE 
CHARACTER 
TO 
C 
;AND 
ECHO 
IT 


jSTORE 
IT 
IN 
BUFFER 
jINCREMENT 
BUFFER 
POINTER 
;INCREMENT 
I OF 
CHARS 
COUNTER 


itS 
IT 
A 
NEWLINE 
CHARACTER 


,SAVE 
HL 
REGISTER 
PAIR 
,SAVE 
PSW 
;GET 
STRING 
POINTER 
INTO 
HL 


;CHECK 
FOR 
PAUSE(CNTL-S) 
,GET 
CHARACTER 
,OUTPUT 
TO 
TERMINAL 


itS 
IT 
A 
<CR>? 


;YES,E~IT 
,INCREMENT 
POINTER 
;DECREMENT 
STRING 
COUNT 


;GET 
HI 
BYTE 
;AND 
WITH 
LO 
BYTE 
;IF 
STRING 
COUNT 
<> 
0 CONTINUE 
iRESTOR£ 
PSW 


iRESTORE 
HL 


;ALL 
THROUGH 


BUFOUT 
ENTRY 
POINT 


0UBLIC 


BUFOUT: 
PUSH 
I 


PUSH 
MOV 
MOV 
OUTCHR: 
CALL 
MOV 
CALL 
MVI 
CMP 
JZ 
INX 
DCX 
MOV 
ORA 
JNZ 


EXITLP: 
POP 
I ~OP 
~ET 


DLTCHR--DELETES 
LAST 
CHAR 
ENTERED 
INTO 
BUFFER 


MOV 
CALL 
MOV 
INX 
INR 
MVI 
CMP 
JNZ 
POP 
POP 
POP 
POP 
RET 


C,A 
ECHO 
M,C 
H 
o 
A,CR 


C 
GETCHR 
o 
B 
PSW 
H 


BUFOUT 
H 


PSW 
H, B 
L,C 
CHKIO 
C,M 
ECHO 
A,CR 


C 
EXITLP 
H 
o 
A,D 
E 
OUTCHR 
PSW 


H 


LOC 
OBJ 
SEQ 
SOURCE 
STATEMENT 


ee91 
F29Bee 
C 
163 
JP 
OLTCle 
IF 
>=e 
CONTINUE 
ee94 
14 
164 
INR 
0 
RUBOUT 
PAST 
START 
OF 
BUFFER 


ee95 
eEe7 
165 
MVI 
C,BELL 
INCREMENT 
COUNT, ECHO 
A 
BELL 


ee97 
COB4ee 
C 
166 
CALL 
ECHO 


ee9A 
C9 
167 
RET 
AND 
RETURN 


168 
OLTCle: 


ee9B 
lC 
169 
INR 
E 
:INC. 
SPACE 
LEFT 
INDICATOR 


ee9C 
2B 
17e 
OCX 
H 
iDECREMENT 
BUFFER 
POINTER 
ee90 
4E 
171 
MOV 
C,M 
;ECHO 
DELETED 
CHARACTER 


ee9E 
COB4e~ 
C 
172 
CALL 
ECHO 


eeAl 
C9 
173 
RET 
;ANO 
RETURN 
174 
175 
DlTLIN--DELETES 
LINE 
BUFFER 
AND 
BEGINS 
REFILL 


176 
177 
OLTLIN: 


eeA2 
eE23 
178 
MVI 
C," 
' 
;ECHO 
A '" 
eeA4 
COB4ee 
C 
179 
CALL 
ECHO 
eeA7 
eEeO 
18e 
MVI 
e,CR 
;ECHO 
A 
CRLF 
eeA9 
COB4 ee 
C 
181 
CALL 
ECHO 


eeAC 
2A8eee 
0 
182 
LHLD 
BUFPTR 
;GET 
ORIGINAL 
POINTER 
8ACK 


eeAF 
01 
183 
POP 
0 
;GET 
COUNTERS 
BACK 


eeBe 
05 
184 
PUSH 
0 
;RESAVE 
eeBl 
C33gee 
C 
185 
JMP 
GETCHR 
;GET 
NEW 
CHARACTERS 


18~ 
187 
ECHO--ECHOES 
CHARACTERS 
TO 
THE 
TERMINAL 


188 
eeB4 
41 
189 
ECHO: 
MOV 
B,C 
,SAVE 
ARGUMENT 
eeB5 
3EIB 
19A 
MVI 
A,ESC 
;SEE 
IF 
ECHOING 
AN 


eeB7 
B8 
191 
CMP 
B 
iESCAPE 
CHARACTER 


eeBB 
C2Boee 
C 
192 
JNZ 
ECH05 
;NO--BRANCH 
e0BB 
eE24 
193 
MVI 
C,' $' 
iYES,ECHO 
AS 
'$ , 


194 
ECHe5 : 
e0BO 
COEEe0 
C 
195 
CALL 
CO 
;OUTPUT 
IT 
eece 
3Eeo 
196 
MVI 
A,CR 
eeC2 
B8 
197 
CMP 
B 
;CHARACTER 
ECHOED 
A 
CR? 


eeC3 
C2CBee 
C 
198 
JNZ 
ECHle 
;NO--SPECIAL 
ACTION 
NOT 
NEEDED 


eeC6 
0EM 
199 
MVI 
c, LF 
iYES--ECHO 
FREE 
LINE 
FEED 


eeC8 
COEEee 
C 
2e0 
CALL 
CO 
2el 
ECHI0: 
eeCB 
48 
202 
MOV 
C,B 
iRESTORE 
i\RGUMENT 
eecc 
C9 
203 
RET 
204 
2e5 
CHKIO--CHECK$ 
FOR 
CNTL-S 
OPERATION 


206 
eeco 
OBEO 
2e7 
CHKIO: 
IN 
CSTS 
;GET 
STATUS 


eeCF 
E6e2 
208 
ANI 
RXROY 
;CHARACTER 
AVAILABLE? 


eeOl 
C8 
209 
RZ 
;NO,RETURN 
ee02 
OBEC 
210 
IN 
COATA 
;YES,GET 
CHARACTER 
ee04 
E67F 
211 
ANI 
7FH 
iSTRIP 
OFr 
PARITY 
ee06 
FE13 
212 
CPI 
CNTLS 
;CONTROL-57 


ee08 
ce 
213 
RNZ 
;NO,IGNORE 
IT 


ee09 
COE2ee 
C 
214 
WAIT4Q: 
CALL 
CI 
;YES,WAIT 
FOR 
A 
CONTROL-Q 


eeoc 
FEll 
215 
CPI 
CNTLQ 


eeOE 
C20ge~ 
C 
216 
JNZ 
WAIT4Q 


eeEl 
C9 
217 
RET 
;GOT 
IT,RETURN 


LOC 
OBJ 
SEQ 
SOURCE 
STATEMENT 


218 
219 
CI--ENTER 
CHARACTER 
FROM 
TERMINAL 
22e 
~eE2 
OBEO 
221 
I: 
IN 
CSTS 
;GET 
STATUS 
BYTE 
e0E4 
E6~2 
222 
ANI 
RXRDY 
;CHARACTER 
AVAILABLE 
00E6 
CAE2~~ 
C 
223 
JZ 
CI 
;NO,LOOP 


0eE9 
OSEe 
224 
IN 
COATA 
;READY,GET 
CHARACTER 


e0EB 
Ef\7F 
225 
ANI 
P'7FH 
;STRIP 
OFF 
PARITY 
00£0 
C9 
226 
RET 
227 
228 
CO--OUTPUT 
CHARACTER 
IN 
C 
REGISTER 
TO 
TERMINAL 


229 
~0EE 
DBED 
23~ 
0: 
IN 
CSTS 
;GET 
STATUS 
BYTE 


eeFe 
E6~1 
231 
ANI 
TXRDY 
;TRANSMITTER 
READY? 


eDF2 
CAEE00 
C 
232 
JZ 
CO 
iNC,LODP 


eeF5 
79 
233 
MOV 
A,C 
iYES,MOVE 
CHARACTER 
TO 
ACC. 


e0F6 
03EC 
234 
OUT 
CDATA 
;SENO 
TO 
TERMINAL 


e0F8 
C9 
235 
RET 
236 
237 
PRTBUF--PRINTS 
CURRENT 
BUFFER(CONTROL-R) 
238 
239 
RTBUF: 


e0F9 
P.E00 
24 e 
MVI 
e,eR 
;ECHO 
CRLF 


00FB 
CDB'~0 
C 
241 
CALL 
ECHO 
0P.FE E5 
242 
PUSH 
H 
iSAVE 
CURRENT 
BUFFER 
POINTER 


2·54 
AFN-01931A 


0flFF 
2A~M~ 
0 
243 
LHLD 
BUFPTR 
;GET 
POINTER 
TO 
BEGINNING 


0102 
D5 
244 
PUSH 
D 
;SAVE 
CURRENT 
CDUNTERS 


2i!5 
PRLOOP: 


el03 
15 
246 
DCR 
D 
;DECREMENT 
CDUNTER 


~le4 
FA~Fel 
C 
247 
JM 
PREXIT 
;NO 
MORE 
CHARACTERS 
IN 
BUFFER 


al~7 
4E 
24B 
MOV 
C,M 
;GET 
CHARACTER 


0108 
CDB4a0 
C 
249 
CALL 
ECHD 
;ECHO 
IT 


0IrB 
23 
7.50 
INX 
H 
;INCREMENT 
POINTER 


01~C 
C3~301 
C 
251 
JMP 
PRLOOP 
;LOOP 
UNTIL 
ALL 
CHARS 
OUTPUT 


252 
PREXIT: 


~10F 
01 
253 
POP 
D 
;RESTORE 
COUNTERS 


0110 
El 
254 
POP 
H 
;RESTORE 
POINTER 


0111 
<33900 
C 
255 
JMP 
GETCHR 
;GET 
NEW 
CHARACTER 


256 
END 


ISIS-II 
FORTRAN-80 
COMPILATION 
OF 
PROGRAM 
UNIT 
MAINLN 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:MAINLN.OBJ 


COMPILER 
INVOKED 
BY: 
FORT80 
:FI:MAINLN.FRT 
DEBUG 
DATE(10/12/78) 
PAGEWIDTH(78) 


© 


MAINLINE 
ROUTINE 
FOR 
TEST 
STAND 
SOFTWARE. 
COMMAND 
LINE 
IS 


SEARCHED 
FOR 
KEYLETTER 
AND 
APPROPRIATE 
ROUTINE 
IS 
CALLED. 


ALL 
UNUSED 
LETTERS 
TRAP 
TO 
ERROR 
ROUTINE. 


CHARACTER 
LINBUF(S0)*I,IMAGE*S0 
INTEGER 
INDEX*2,CARRET*I,KEYLTR*I,ERRFLC*2,DUMMY*2 


COMMON 
/LINE/ 
LINBUF,INDEX,CARRET 
EQUI 
VALENCE 
(LINBUF, 
IMAGE) 


DATA 
CARRET 
1131 


Cc-- 
INITIALIZE 
SYSTEM 


C@ 


DUMMY=lo 
E: 
CALL 
FQFSET(DUMMV,DUMMV) 


Cc-- 
WRITE 
BANNER 


C 
1~ 
1 
WRITE(IM~GE,1r"IOSTAT=ERRFLC,ERR=999) 
CARRET 
110 
1I:J 
FORMAT( 
'TEST 
STAND 
vr..e' 
,A) 


F ~__OUTPUT 
BUFFEH 


C 


C 
C-- 


C 
13@{ 


C 


C 
C-- 
17@: 


C-- 


18Q): 


C-- 
C 
~:0c 


C 
c-- 


C 
C 
23®c 


WRITErIMAGE,1~,IOSTAT=ERRFLC,ERR=999) 
CARRET 
FORMAT( 
'COMMAND?' 
,A) 


CALL 
BUFOUT(IMAGE) 


ABC 
0 
E 
F 
CHI 
J 
K 
L 
M 
N 


GOTO(30~, 
100, 
HJr., 10"", 10(', 
100, 
10~, 
Je"", 
Ifl~, 
H'J,,", Ie,,", 
100, 
lOP, 
HJ!3, 
o 
P 
Q 
R 
S 
T 
U 
V 
_ 
X 
Y 
Z 
C10 "', 1~0, 10 P, 10"', 3~ "',2ft 0. le ~, Ha' , Ie'''. 
1Ze, 100, 
100) 
KEYLTR 


C 
C-- 
IF 
INVALID 
OUTPUT 
ERROR 
AND 
GET 
NEW 
LINE 


C 


WRITE(IMAGE,40,IOSTAT=ERRFLG,ERR=999) 
CARRET 


FORMAT('INVALID 
KEYLTR',A) 


CALL 
BUFOUT(IMAGE) 


GOTO 
20 


C 
C-- 


C 
C 
C-- 


C 


1~0 
110 
WRITE(IMAGE,110,rOSTAT=ERRFLG,ERR=999l 
CARRET 
FORMAT('NO 
SUCH 
TEST',A) 
CALL 
BUFOUT(IMAGE) 


GOTO 
20 


C 
C-- 
TRANSITION 
TEST 


C 
3345fi"\L 
200 
CALL 
TRANST 
\!;.I 
GOTO 
20 
C 
C-- 
CALCULATOR 
MODE 


C 
36 
30e 
CALL 
MATH 


37 
GOTO 
2~ 
C 
C-- 
ERROR 
HANDLER 


C 
38 
999 
CALL 
ERROR(ERRFLG) 
39 
GOTO 
1 


40 
END 


ISIS-II 
FORTRAN-80 
COMPILATION 
OF 
PROGRAM 
UNIT 
DB LANK 
OBJECT 
MODULE 
PLACED 
IN 
:FI:DBLANK.OBJ 
COMPILER 
INVOKED 
BY: 
FORT~0 
:F) :DBLANK.FRT 
DEBUG 
DATE(IO/12/7~) 
PI\GEWIDTfI(78) 


® 


C 
C-- 
POSITIONS 
INDEX 
TO 
NEXT 
NON-BLANK 
CHARACTER 
IN 
LINBUF 


C 
INTEGER 
INDEX*2,CARRET*1,ERRFLG*2 


CHARACTER 
LINBUF(80)*1,IMAGE*Se,ENDLIN*1 


EQUIVALENCE 
(LINBUf,IMAGE), 
(ENDLIN,CARRET) 


COMMON 
/LINE/ 
LINBUF,INDEX,CARRET 


C 
7 
1 
IF(LINBUF(INDEX) 
.EQ.ENOLIN) 
GOTO 
, 
8 
IF(LINBUF{INDEX) 
.NE. 
I 
I) 
RETURN 
9 
INDEX=INDEX+] 


10 
IF(INDEX.LE.72) 
GOTO 


C 
C-- 
IF 
END 
OF 
LINE 
ASK 
FOR 
MORE 
PI\RAMETERS 


C 


11 
2 
WRITECIMAGE,3,rOSTAT=ERRFLG,ERR=999) 
CARRET 


12 
3 
FORMAT('MISSING 
PARAMETER, PLEASE 
ENTER',A) 


13 
CALL 
BUFOUT(IMAGE) 
14 
CALL 
BUFIN 
(IMAGE) 
15 
INDEX=1 
16 
GOTO 
1 


C 
C-- 
ERROR 
HANDLER 


C 


17 
999 
CALL 
ERRDR(ERRFLG) 
18 
RETURN 


19 
END 


ISIS-II 
FORTRAN-8~ 
COMPILATION 
OF 
PROGRAM 
UNIT 
ERROR 


OBJECT 
MODULE 
PLACED 
IN 
:F):ERROR.OBJ 
rOMPI LER 
r NVOKED 
BY: 
PORT~ ~ 
:PI: ERROR. FRT 
DEBUG 
DATE (]e/ ]2/78) 
PAGEWIDTH 
(78) 


® 


C 
c-- 
OUTPUT 
ERHQR 
MESSAGE 


C 


CHAHACTf.R 
IMAGE*~e,LINBUF(80)*1 
INTEGER 
ERRNUM*2,INDEX*2,CARRET*1 
EQUIVALENCE 
CLINBUF,IMAGE) 


CCMMON 
/LINE/ 
LINBUF,INOEX,CARRET 


~RITE(IMAGE,16) 
ERRNUM,CAHR~T 
FORMAT('***ERROR*** 
*' 
,I4,A) 
CALL 
BUFOUTIIMAGE) 


RETURN 
END 


ISIS-II 
FORTRAN-8~ 
COMPILATION 
OF 
PROGRAM 
UNTT 
MATH 


OBJECT 
MODULE 
PLACf.D 
IN 
:Fl:MATH.OBJ 
CO~PIL£R 
INVOKED 
BY, 
FORTRr 
:FI,MATH.FRT 
DEBUG 
D~TECln/12/7R) 
PAGEWIDTHI7B) 


@ 


C 
C-- 
IMPLEMENTS 
CALCULATOR 
MOD~ 


C 


INTE~ER 
INDEX*2,CARRET*l,ERRFLG*2 


CHARACTER 
L INBUF 
(8~) ."1,IMAG E *'=1 e,COMMND* 
J , SYMBOL 
* 1 


REAL 
OPl,OP2.R~SULT 


EQUIVALENCE 
ILINBUF,IMAGE) 


COMMON 
/LINE/ 
LINBUF.IND~X,CARRET 


Cc-- 
RESCAN 
KEYL~TT~H 
'fO DETERMINE 
OP~RATJON 


r 
® 


INDEX=INDEX-l 
COMMND=LINBUF{JNDEX) 
INDI:::X=JND~X+] 


c 
C-- 
MOVE 
INDEX 
1'0 rIlis'rOPERAND 


c 
CALL 
DB LANK 


C 
(-- 
GET 
IT 
IN 


C 
CALL 
rONVRT 
(DP 1) 
( 
c-- 
REPEAT 
FOR 
SECOND 
OPERAND 


r 
)' 
CALL 
OBLANK 


14 
CALL 
CONVRT(OP7.\ 
(. 
c-- 
PERFORM 
OPERATION 


IF (COMMND. 
EQ. 'M') 
THEN 


RESULT=OP1*OP? 
SYMBOL='*' 
GOTO 
1] 


ENOIF' 


IF(COMMND.EQ. 
'D') 
THEN 
RESULT=OPI/OP2 
SYMBOL=' 
/' 


GOTO 
II 


ENDrF 


IF(COM,..ND.E('.'A') 
THEN 
RESULT=OP!+OP] 
SYMBOL=' 
+' 


GOTO 
II 


fNDIF 


31 
RESULT=OPI-OP2 
32 
SYMBOL='-' 


33 
GOTO 
II 


34 
ENOIF 


C 
C-- 
OUTPUT 
RESULTS 


C 
35 
11 
WRITE(IMAGF,l2,IOSTAT=ERRFLG,ERR=999) 
OPl,SYM80L,OP2,RESUL'r, 


ICARRET 


36 
12 
FORMAT 
(Fla. 5, IX, A,lX, F'le. 5, IX, '=', 
IX, F'18. 
5,,A) 


37 
CALL 
BUFOUTCIMAGE) 


3B 
RETURN 


C 
C-- 
ERROR 
HANDLER 


C 
39 
999 
CALL 
ERRORIERRFLG) 
40 
RETURN 
41 
END 


ISIS-II 
FORTRAN-80 
COMPILATION 
OF 
PROGRAM 
UNIT 
CQNVRT 


OBJECT 
MODU LE 
PLACED 
IN 
: F 1: CQNVRT. 
QBJ 


COMPILER 
INVOKED 
bY, 
FORTBr 
,Fl,CONVRT.FRT 
DEbUG 
DATE(10/12/7B) 
PAGEWIDTH(78) 


® 


SUBROUTINE 
CONVRT 
(VALUE) 


IMPLICIT 
LOGICAL(A-Z) 


C 
C-- 
INPUTS 
NEXT 
PARAMETER 
IN 
LINBUF 


C 


INT~GER 
1.1, 
INDEX" 
2, 
TMPIND* 
1 ,CARRET* 
1, 
ERRFLG* 
2 
REAL 
VALUE 


CHARACTER 
LINBUF 
(e:~) 
*] ,TMPBUF 
(20)"] 
, BUFFER* 
20, 
ENDLIN* 
1 


EQUI 
VALENCE 
(TMPBUF, 
BUFFER) 
, (ENDLIN, 
CARRET) 


COMMON fLINE/ 
LINBUF, 
INDEX, 
CARRET 


C 
c-- 
INITIALIZE 


C 


DO 
21 
1=],19 


TMPBUF(I)=' 
, 


TMPBUf' 
(20) 
=ENDLIN 


TMPIND=] 


C 
C-- 
FILL 
BUFFER 
UNTIL 
COMMA 
OR 
ENDLINE 
ENCOUNTERED 


Cn uMPBUF 
(TI'1PIND) =LINBUF (INDEX) 
INDEX=INDEX+l 
'IMPIND=TMPIND+ 
1 
® 


IF{LINBUF(INDEX).EQ.',') 
THEN 
5 
~~~~X;~ND~X+l 


ENDIF 
IF{LINBUF(INDEX) 
.EQ.ENDLIN) 
G010 
23 


GOTO 
22 


C 
C-- 
READ 
UNDER 
FORMAT 
CONTROL 


C 


21@,23 
22 
T 
24 


2.' 
C 
C-- 
ERROR 
HANDLER 


C 
999 


READ 
(BUFFER, 
24, IOS1'AT=ERRFLG, 
ERR=999) 
VALUE 


FORMAT 
(F19. 5) 
RETURN 


CALL 
FRROR (ERRFLG) 
RETURN 
END 


ISIS-II 
FORTRAN-8~ 
COMPILATION 
OF 
PROGRAM 
UNIT 
TRANST 
OBJECT 
MODULE 
PLACED 
IN 
,Fl,TRANST.OBJ 
COMPILER 
INVOKED 
BY, 
FORT80 
,F1,TRANST.FRT 
DEBUG 
DATCI10/l2/78) 
PAGEWIDTH(78) 


C 
C-- 
PERFORM 
TRANSITION 
TESTING 
C 


C 
C-- 
INITIALIZE 


C 


00 
5, 
I=1,2e 


TEST(I)='PASSEO' 
TSTINP=0 
PNTCNT=l 


CALL 
DB LANK 


CALL 
CONVRT(STARTI 
CALL 
OBLANK 


CALL 
CONVRT(STOP) 
CALL 
DBLANK 


CALL 
CONVRT(STEP) 
CALL 
DBLANK 


CALL 
CONVRT (TOL) 


C 
C-- 
IF 
(STOP-START)/STEP 
YIELDS 
MORF 
TIIAN 
2" 
STEPS 


C-- 
OUTPUT 
MESSAGE 
AND 
RETURN 


C 
IF(IFIX((STDP-START)/STEPI.GT.20) 
TIIEN 


WRITE(IMAGE,le,IOSTAT=ERRFLG,ERR=999) 
CARRET 


FORMAT ('TOO 
MANY POINTS' 
,AI 


CALL 
BUFOUT(IMAGE) 
RETURN 
ENDIF 


C 
C-- 
GET 
TEMPERATURE 
AND 
LINEARIZE 


C 
@ 


c 
C-- 
CUTPUT 
HEADER 


C 


WRITE(IMAGE,20,IOSTAT=ERRFLG,ERR=999) 
TOL,TEMP,CARRET,CARRET 


FORMAT( 
'TRANSITION 
TEST 
TOLERANCE=' 
,F5.1, 


J '% 
AMBIENT 
TEMPERATURE 
= 
" ff'. 2,' 
DEGREES 
C' ,A,A) 


CALL 
BUFOUT(IMAGE) 
WRITE 
fIMAGE, 
3e, 
IOSTAT=FRR' 
LG, ERR=999) 
CARRET,CARRET 


fORMATe' 
VCC 
HIGH 
TRANS 
LOW 
TRANS 
HIGH 
LOW 
TEST', 
IA,A) 
CALL 
BUFOUT(IMAGE) 


C 
c-- 
BEGIN 
TEST; 
OUTPUT 
STARTING 
VCC 
VJ>LUE 


C 
VOLTAC=START 
VCC (PNTCNT) 
=VOLTAG 


CALL 
DACOUT(IFIX(VOLTAG'4P9.61 
,01 


C 
C-- 
OUTPUT 
ZERO 
VOLTS 
TO 
TEST 
INPUT 


37@: 
CALL 
DACOUT(TSTINP,l) 


c-- 
GET 
ONE 
SAMPLE 


C 


C 
C-- 
MAKE 
IT 
TH~ 
LAST 
S~MPLE A~D 
ALSO 
STORE 
IT 


C 
39 
LSTfAM=SAMPLE 
4~ 
LOWLVL(PNTCNT)=FLOAT(~AMPLE)·4~9.~ 


C 
C-- 
PECIN 
LOOP 
LOOKING 
fOR 
LO~ 
TO 
HIGH 
TRANSITION 


C 


41 
5e 
rSTINP=TSTINP+l 
42 
CALL 
DACOUT(TSTINP,ll 


C 
C-- 
GfT 
SAMPLE 


C 


c 
C-- 
SEE 
IF 
TRANSITION;DELTA 
.GT. 
2.' 
VOLTS 


C 


C 
c-- 
~O 
TRANSITION; 
If 
TSTINP 
NOW 
UP 
TO 
5.5V 
AND 
NO 
TRANSITION 


c-- 
OUTPUT 
MESSAGE 
INDICATING 
DEAD 
PART 
AN[ 
RETURN 


tp ® 
(WRITE 
(JMAGE,I;~, 
IOSTl\T=ERRFLG,ERR=999l 


49 
W 
60 
FORMl\T( 
'DEAD 
PART, 
NO TRANSITION' 
,Al 


or 
CALL 8UfOUT(I"~GEI 


51 
RETURN 


52 
[NDIF 


Cc-- 
CONTINUE 
LOOP 


Cc-- 
TRANSITION; 
ASSIGN 
ARRAY 
ELEMENT 


C 


Cc-- 
CHECK 
TOLERANCE 


C 


C 
C-- TEST "ILEn 


C 


C 
c-- 
BEGIN 
HIGH 
TO 
LOW 
TEST 


C 
C 
C-- OUTPUT 5.0 VOLTS 
C 
58 
70 
TSTINP=2048 
S9 
CALL 
DACOUT(TSTINP,l) 


Cc-- 
GET 
SAMPLE 


C 


Cc-- 
MAKE 
IT 
LAST 
SAMPLE 
AND 
ALSO 
STORE 
IT 


C 
61 
LSTSAM=SAMPLE 


62 
HILVL(PNTCNT)=FLOAT(SAMPLE)*4~9.~ 


Cc-- 
BEGIN 
LOOP 
LOOKING 
FOR 
HIGH 
TO 
LOW 
TRANSITION 


C 
63 
80 
TSTINP=TSTINP-I 
64 
CALL DACOUT(TSTINP,I) 
Cc-- 
GET 
SAMPLE 


C 


C 
c-- 
SEE 
IF 
TRANSITION; 
DELTA 
.CT. 
2.7 
VOLTS 


C 


Cc-- 
NO 
TRANSITION; 
CHECK 
TO 
SEE 
IF 
VOLT~GE 
DOWN 
TO 
ZERO 


C 


Cc-- 
YES; 
OUTPUT 
DEAD 
PART 
MESSAGE 


C 


cc-- 
CC'NTINUE 
LOOP 


C 


c 
c-- 
CHECK 
TOLP.RANCE 
C 


76 
TEST(PNTCNT)-'FAILED' 


C 
C-- 
INCREME;NT 
VC'C AND 
IF 
NOT 
.GT. 
STOP 
CONTINUE 


C 


79 
9~ 
VOLTAG-VOLTAG+STEP 


Be 
IF(v6LT~G.LE.STOP) 
THEN 


el 
PNTCN~=PNTCNT+l 


82 
TSTINP=e 


83 
GOTO ~e 


3' 
ENDIF 


C 
C-- 
TEST 
CO~PLETE; 
OUTPUT 
RESULTS 


C 
85 
DO 
11P,J=1,PNTCNT 


B(, 
WRITE(IMAGE,lee,IOSTAT=ERRFLG,ERR=999) 
VCC(I), 


ILOTOHI 
(I) ,HITOLO(I), 
HILVL 
(I), LOWLVL 
(I) ,TEST (I) ,CARRET 


87 
If'0 
FORMAT (3X,F5. 
2, 3X,Ffi. 
2,6X,F6. 
2,3X,F6. 
2, lX,F6. 
2,2X, 
6A,A) 


e8 
JI~ 
CALL 
BUFOUT(IMAGEj 


89 
RETURN 


c 
C-- 
ERROR 
HANDLER 


C 
9~ 
999 
CALL 
ERROH(ERRF'LGj 
91 
RETURN 


92 
END 


ISIS-II 
FORTRAN-Be 
COMPILATION 
OF 
PROGRAM 
UNIT 
ADCIN 


OBJECT 
MODULE 
PLACED 
IN 
:FI:ADCIN.CBJ 


COMPILER 
INVOKED 
BY: 
FORTee 
:FI:ADCIN.FRT 
DEBUG 
DATE(Ie/I2/78) 
PAGEWIDTH(78) 
® 


C 
c-- 
ROUTINE 
TO 
INPUT 
SINGLE 
VALUE 
FROM 
A/D 
CONVEnTER 
CHANNEL 
c-- 
GIVEN 
AND 
RETURN 
IT 
IN 
VALUE 
FIELD. 


C 
INTEGER·;> 
VALUE 
INTEGER*l 
CHAN 


SINCLUDE(:Fl:ADCDAC.DECj 
Cc-- 
DEFINITIONS 
OF 
TSBC 
712 
REGISTERS 


C 
C 
C-- 
COMMAND 
STATUS 
REGISTER 


C 


Cc-- 
MUX 
ADDRESS 
REGISTER 


C 


C 
C-- 
LAST 
CHANNEL 
REGISTER 


C 
INTEGER*l 
LSTCHN 


C 
C-- 
CLEAR 
INTERRUPT 
COMMAND 
WORD 


C 
INTEGER·l 
CLRINT 


C 
C-- 
ADC 
DATA 
REGISTER 


C 


INTEGER*2 
ADCDAT 


C 
C-- 
DAC 
Po DATA 
REGISTER 


C 


INTEGER*2 
DACV 


C 
C-- 
DAC 
I DATA 
REGISTER 


C 


C 
C-- 
SET 
UP 
COMMON 
BLOCK 


C 


Cc-- 
SET 
UP 
CHANNEL 
ADDRESS 
C 


Cc-- 
START 
CONVERSION 


C 


cc-- 
W"IT 
fOR 
END 
OF 
CONVERSION 


C 


J' 
J 
[f«CMDSTS.AND.f8~H).NE.f80H) 
GOTO 
1 


C 
C-- 
GE" 
DATA 
IN 


C 


J <; 
VA LUE-=ADCDAT 


C 
(-- 
nIGHT 
JUSTIFY 
AND 
CONVERT 
TO 
COUNTS 


C 


17 
VALUE=VALUE/16 


J 8 
IFIVALUE.LT.n) 
VALUE=VALUE+4096+1 
19 
RETURN 


2~ 
END 


ISIS-II 
FORTRAN-8" 
COMPILATION 
OF 
PROGRAM 
UNIT 
DACOUT 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:DACOUT.OBJ 
COMPILER 
INVOKED 
BY: 
FORTS0 
:Fl:DACGUT.FRT 
DEBUG 
OAT£(10/12/78) 
PAGEWIDTH(78) 


INTEGER*2 
VALUE,CHAN 
$INCLUDE 
( : F 1 :ADCDAC. 
DEe) 
cc-- 
DEFINITIONS 
OF 
ISBC 
732 
REGISTERS 
C 
Cc-- 
COMMl'.ND 
STATUS 
REGISTER 


C 


cc-- 
MUX 
ADDRESS 
RE:CIS1'ER 


C 


C 
c-- 
LAST 
CHANNEL 
REGISTER 


C 


INTEGER'" 
1 
LSTCHN 


C 
c-- 
CLEAR 
INTERRUPT 
COMMAND 
weRD 


C 


INTEGER·l 
CLRINT 


C 
c-- 
'DC 
DATA 
REGISTER 
C 
INTEGER*2 
ADCDAT 


C 
c-- 
DAC " 


DATA 
REGISTER 


C 


IN'l'EGER*2 
OAC" 


C 
c-- 
DAC 
] 
DATA 
Rf::GISTER 


C 


INTEGER"2 
DACI 


C 
c-- 
SET 
UP 
COMMON 
BLOCK 


C 


c 
C-- 
OUTPUT 
VALUE 
TO 
PROPER 
CHANNEL 


C-- 
AFTER 
SHIFTING 
INTO 
HIGH 
ORDER 
12 
BITS 
C 


IF (VJl.LUE. 
LT. 0) 
VALUE=VALUE+4 
096+ 
1 
VALUE=VALUE*16 
IF (CHAN. 
EQ.~) 
DAC0=VlILUE 
IF 
(CHAN. 
EQ.]) 
DAC ]=VALUE 


RETURN 
END 


APPENDIX 
B 
CODE LISTINGS 


ISIS-II 
PL/M-8~ 
V3.1 
COMPILATION 
OF 
MODULE 
SEMAPHORES 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:SEMMOD.OBJ 
COMPILER 
INVOKED 
BY: 
plm80 
:Fl:SEMMOD.plm 
DEBUG 
DA'fE(l~/12/78) 
PAGEWIDTH(78) 


2~® 


Contains 
LOCK 
and 
UNLOCK 
procedures 
for 
manipulating 
semaphores. 
Called 
by 
FORTRAN 
routines 
with 
one 
parameter: 
the 
address 
of 


the 
index 
of 
the 
semaphore 
to 
be 
operated 
on. 


DECLARE (stslok,setlok,dsklok) 
(10) 
BYTE PUBLIC; 


DECLARE 
semaphore()) 
ADDRESS 
PUBLIC 
DATA( 


.stslok, 
.setlok, 
.dsklok); 
DECLARE 
token 
(3) 
STRUCTURE 
( 
link 
ADDRESS, 
length 
ADDRESS, 


type 
ADDRESS) 
PUBLIC; 


LOCK: 
PROCEOURE(sema$numberSptr) 
REENTRANT 
PUBLIC: 


DECLARE 
semaSnurnber$ptr 
ADDRESS; 
DECLARE 
semaSnumber 
BASED 
semaSnumber$ptr 
BYTE: 
DECLARE 
msg$ptr 
ADDRESS; 


msg$ptr=RQWAIT(semaphore(sema$number),~); 
RETURN: 
END; 


® 
END 


CALL 
RQSEND(semaphore(sema$numher) 
,.token(sEma$number)); 


RETURN: 
END; 
SEMAPHORES; 


ISIS-II 
FORTRAN-Be 
COMPILATION 
OF 
PROGRAM 
UNIT 
STSINP 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:STSMOD.OBJ 
COMPILER 
INVOKED 
BY: 
FORT80 
:Fl:STSMOD.FRT 
DEBUG 
DATE(10/12/78) 
PAGEWIDTH(78) 


C 
C-- 
9@C 


10 


C 
C-- 
II®: 


C-- 
C 
12®10 
F 
CC-- 
C 


© 


TASK 
CODE 
FOR 
STATUS 
INPUT 
TASK. 
UPDATES 
STATUS 
COMMON 
BLOCK 
WITH 
ANALOG 
AND 
DIGITAL 
DATA 
VALUES. 
ALSO 
DOES 


ANALOG 
COUNT 
TO 
ENGINEERING 
UNIT 
CONVERSIONS. 


CHARACTER 
SMPLBF*22,CLOCK*12 


INTEGER*2 
SAMPLS(ll),DUMMY 
REAL 
ANDATA 
(II) 


EQUIVALENCE 
ISMPLBF,SAMPLS) 


INTEGER*l 
DIGDAT,I 
COMMON 
/STATUS/ 
ANDATA,DIGDAT,CLOCK 


CALL 
SMPLIN(SMPLBF) 


SHIFT 
SAMPLS 
TO 
RIGHT 
JUSTIFY 


~~@ 
15 
50 
C 
C-- 
C-- 
C 


DO 
50 
1=1,11 
SAMPLS(I)=SAMPLS(I)/I6 
IFISAMPLSII).LT.0) 
SAMPLS(I)=SAMPLS(I)+4096+1 


WAIT 
FOR 
ACCESS 
TO 
STATUS 
COMMON 
BLOCK 
FOR 
UPDATE 
THEN 
CONVERT 
SAMPLES 
TO 
ENGINEERING 
UNITS 
AND 
STORE 


CALL 
LOCK(0) 
ANDATA(I)=FLOAT(SAMPLS(I» 
ANDATA(2)=ALOGI0(FLOAT(SAMPLS)*2.34)-365.9B 
ANDATA(3)=ALOGI0(FLOAT(SAMPLS(3)/I3.9)-2I.5' 
ANDATA(4)=I3.23*FLOATISAMPLS(4»-2~.78 
ANDATA(5)=FLOAT(SAMPLS(5» 
ANDATA(6)=FLOAT(SAMPLS(6f)/I4.225 
ANDATA(7)=FLOAT(SAMPLS(7» 
ANDATA(8)=ALOG(FLOAT(SAMPLSI8)/23.98)+235.98 
ANDATA 
(9) =FLOAT 
(SAMPLS 
(9» 


ANDATA(IA)=FLOAT(SAMPLS(I0» 
. 


ANDATA 
(11) = (FLOAT (SAMPLS 
(11» 
-119. 34) /5. 734 
CALL 
INPUT('0EOH,DIGDAT) 


® 


C 
C-- 
DELAY 
FOR 
1 SECOND 
THEN 
SCAN 
AGAIN 


3~G): 
CALL 
WAIT 


C-- 
LOOP 
BACK 


C 
31 
GOTO 
I~ 


32 
END 


ISIS-II 
PL/M-8e 
V3.1 
COMPILATION 
OF 
MODULE 
ANALOGIOMOD 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:aiomod.OBJ 


COMPILER 
INVOKED 
BY: 
plm80 
:Fl:aiomod.plm 
DEBUG 
DATE(10/12/78) 
PAGEWIDTH(78) 


Snolist 


24 
1Q) 
DECLARE 
ANSRESP 
(10) 
BYTE 
PUBLIC; 


25 
1 
DECLARE 
ANALOG$REQUEST$MESSAGE 
aiSmsg; 


1* 
initializes 
mesage 
to 
be 
used 
for 
analog 
samples 
*/ 


27 
2 
UNALOr,SREQUESTSMESSAGE. 
Ien9th=size 
(ANALOGSREQUESTSMESS 
AGE); 


28 
2@ 
ANALOGSREQUESTSMESSAGE.type=AISQS; 


29 
2 K 
ANALOGSREQUEST$MESSAGE.response$exchange=.ANSRESP; 


30 
2 
ANALOGSREQUESTSMESSAGE.baseSptr=0FFF0H; 


31 
2 
ANALOG$REQUEST$MESSAGE.channelSg~in=0; 


32 
2 
RETURN; 


33 
2 
END; 
/* of 
INIT$IO 
*/ 


DECLARE 
(sampleSbuffer$ptr,bufSsize,dummy) 
ADDRESS; 


DECLARE 
sampleSbuffer 
BASED 
sampleSbuffer$ptr 
(1) 
BYTE; 


ANALOGSREQUESTSMESSAGE.arraySptr=sampleSbuffer$ptri 
ANALOG$REQUESTSMESSAGE.count=bufSsize/2; 


ISIS-II 
FORTRA~78~ 
COMPILATION 
OF 
PROGRAM 
UNIT 
SCAN 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:SCANMD.OBJ. 


COMPILER 
INVOKED 
BY: 
FORT80 
:Fl:SCANMD.FRT 
DEBUG 
DATE(I~/12/78) 
PAGEWIDTH(78) 


C 
C-- 
CODE 
FOR 
SCAN 
TASK 
THAT 
COMPARES 
STATUS 
VALUES 
WITH 
C-- 
SETPOINTS 
AND 
SETS 
OPERATOR 
ALARMS 
ACCORDINGLY. 
ALSO 


C-- 
LOGS 
DISK 
RECORD 
OF 
STATUS 
WHEN 
MIN5UP 
FLAG 
IS 
TRUE. 


C 


2 
$INCL 
DE(:Fl:EQUIV.DEC) 


3 
CHARACTER 
BUFFER"57,PARAMS(57)"1 


4 
REAL 
PH,VOLUME,TEMP,DISOXY,TOTCAR,ORGCAR 
5 
REAL 
SUSSOL,PHOSFT,INFLOW,EFLFLO,TURBID 
6 
INTEGER·! 
DIGDAT 
7 
INTEGER*2 
MONTH,DAY,YEAR,HOUR,MINUTE,SECOND 
8 
EQUIVALENCE 
(PARAMS,BUFFER) 


9 
EQUIVALENCE 
(PARAMS,PH) 
10 
EQUIVALENCE 
(PARAMS(5) 
,VOLUME) 
11 
EQUIVALENCE 
(PARAMS 
(9) ,TEMP) 
12 
EQUIVALENCE 
(PARAMS(13) 
,DISOXY) 
13 
EQUIVALENCE 
(PARAMS(17),TOTCAR) 
14 
EQUIVALENCE 
(PARAMS(21),ORGCAR) 


15 
EQUIVALENCE 
(PARMS 
(25) ,SUSSOL) 


16 ® 
EQUIVALENCE 
(PARAMS 
(29) ,PHOSFT) 


17 
EQUIVALENCE 
(PARAMS(33) 
,INFLOW) 


18 
EQUIVALENCE 
(PARAMS 
(37) ,EFLFLO) 


19 
EQUIVALENCE 
(PARAMS(41) 
,TURBID) 


20 
EQUIVALENCE 
IPARAMS(45),DIGDAT) 


21 
EQUIVALENCE 
(PARAMS(46) 
,MONTH) 


22 
EQUIVALENCE 
(PARAMSI48) 
,DAY) 


23 
EQUIVALENCE 
(PARAMS(50) 
,YEAR) 


24 
EQUIVALENCE 
(PARAMS(52) 
,HOUR) 


25 
EQUIVALENCE 
(PARMS 
(54) ,MINUTE) 


26 
EQUIVALENCE 
(PARAMSI56) 
,SECOND) 


27 
INTEGER*2 
ERRFLG,RECNO,DUMMY 
28 
REAL 
SETSOL,SETCAR,SETPHS,SETTRB 
29 
INTEGER"1 
MIN5UP 
30 
COMMON 
/MIN5/ 
MIN5UP 
31 
COMMON 
/SETPNT/ 
SETPHS,SETSOL,SETCAR,SETTRB 
32 
COMMON 
/STATUS/ 
BUFFER 
33 
COMMON 
/LSTREC/ 
RECNO 


C 
C-- 
INITIALIZE 
RECORD 
COUNTER 
C 


C 
C-- 
INITIALIZE 
MATH 
LIBRARIES 


C 
35 
DUMMY=0 
36 
CALL 
FQFSET(DUMMY,DUMMY) 


C 
C-- WAIT 
FOR 
ACCESS 
TO 
STATUS 
AND 
SETPOINT 
COMMON 
BLOCKS 


C 
37 
10 
CALL 
LOCK (0) 


38 
CALL 
LOCK(I) 


C 
C-- 
SCAN 
FOR 
ALARMS 
ONLY 
IF 
EFFLUENT 
PUMP 
IS 
ON 


C 


® 


IF I IDIGDAT. 
AND. 1B4H) .EQ. f04H) 
THEN 


IF(PHOSFT.GT.SETPHS) 
THEN 


CALL 
OUTPUTI,0E8H,f01H) 


ELSE 
CALL 
OUTPUT('0EBH,f00H) 


ENDIF 
IFISUSSOL.GT.SETSOL) 
THEN 


CALL 
OUTPUTI'0EBH,f03H) 


ELSE 
CALL 
OUTPUT(I~EBH,f02H) 


ENDIF 
IF(TOTCAR.GT.SETCAR) 
THEN 


CALL 
OUTPUT(I~EBH,I~5H) 
ELSE 


l 


CALL 
OUTPUT(#~EBH,#~4H) 
ENDIF 
® 


IF(TURBID.GT.SETTRB) 
THEN 
CALL 
OUTPUTI#0EBH,#~7H) 
ELSE 
CALL 
OUTPUTI#~EBH,#06H) 
ENDIF 
END IF 


C 
C-- 
IF 
MIN5 
TASK 
HAS 
SET 
MIN5UP 
LOG 
STATUS 
ON 
DISK 


61 @C 
IF(MIN5UP.NE.O) 
THEN 


02 
MIN5UP=0 


C 
C-- 
WAIT 
FOR 
ACCESS 
TO 
OISK 


C 
[CALL 
LOCK (2) 
OPENI3.FILE=':D0:TODAYS.RPT',STATUS='OLD',IOSTAT=ERRFLG, 


JERR=9~0e,ACCESS='DIRECT',RECL=57) 
® 


WRITE(3,REC=RECNO,IOSTAT=ERRFLG,ERR=9100) 
BUFFER 
RECNQ=RECNO+l 
CLOSE 
(3,IOSTAT=ERRFLG,ERR=92r0) 
CALL 
UNLOCK(2) 
ENDIF 


C 
C-- 
RELEASE 
LOCK 
ON 
STATUS 
AND 
SET POINT 
COMMON 
BLOCKS 


C 
7~ 
CALL 
UNLOCK 
11) 


71 
CALL 
UNLOCK 
Ie) 


C 
C-- 
DELAY 
FOR 
1 SECOND 
THEN 
SCAN 
AGAIN 


C 
72 
CALL 
WAIT 


C 
C-- 
LOOP 
BACK 


C 
73 
GOTO 
l~ 


Cq-- 
ERROR 
HANDLERS 


74@ 
C 
9000 
WRITE(n,9001) 
ERRFLG 
75 
9001 
FORMAT('OPEN 
ERROR 
IN 
SCAN; 
t' , 14) 
76 
GOTO'10 
77 
9100 
WRITE(6,9101) 
ERRFLG 
78 
9101 
FORMAT 
( 
I WRITE 
ERROR 
IN 
SCAN; 
" 
,14) 
79 
GOTO 
10 
80 
9200 
WRITEI6,9201) 
ERRFLG 
81 
9201 
FORMAT 
( 
I CLOSE 
ERROR 
IN 
SCAN; 
, ',14) 
82 
GOTO 
10 
83 
END 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MODULE 
MIN5MOD 
OBJECT 
MODULE 
PLACED 
IN 
:FI:MIN5MD.OBJ 


COMPILER 
INVOKED 
BY: 
plm8e 
:Fl:MIN5MD.plm 
DEBUG 
DATEI10/12/78) 
PAGEWIDTH(/8) 


This 
module 
contains 
the 
code 
for 
TIMERS5 
who 
waits 
for 
5 
minutes 
and 
sets 
a 
flag 
telling 


SCAN 
to 
log 
a 
report 
on 
the 
disk, 
and 
for 
WAIT 
who 
waits 
for 
1 
second 
then 
returns 


DECLARE 
minSSSex 
(l0) 
BYTE 
PUBLIC: 
DECLARE 
minS5Su? 
BYTE 
AT(0FFEEH); 
DECLARE 
timeSout$msgSptr 
ADDRESS; 
DECLARE 
five$minute$delay$count 
LITERALLY 
'6000'; 
DECLARE 
timesSup 
LI'rERALLY 
'0lH'; 


® 


DO 
WHILE 
Ii 


timeSoutSmsg$ptr=RQWAIT(.minSSSex,fiveSminuteSdelay$count); 
minSSSup=times$upi 
END; 
/* 
of 
do 
while] 
*/ 


ENDi 
/* 
of 
procedure 
*/ 


END; 
/* 
of 
module 
*/ 


ISIS-II 
PL/M-8e 
V3.1 
COMPILATION 
OF 
MODULE 
REPORT 


OBJECT 
MODULE 
PLACED 
IN 
:FI:RPTMOD.OBJ 
COMPILER 
INVOKED 
BV: 
plmae 
:Fl:RPTMOD.plm 
DEBUG 
DATE(le/12/7B) 
PAGEWIDTH(78) 


This 
module 
contains 
the 
code 
for 
the 
REPORT 
task 
that 
prints 
formatted 
reports 
of 
system 
status 
upon 
command. 
Commands 
come 
in 
from 


PRTREQ 
exchange 
with 
type=100 
for 
todays 


status 
report 
and 
type 
= 
101 
for 
yesterday's 
status 
report. 
PRINT 
is 
the 
FORTRAN 
routine 
that 
does 
the 
actual 
work. 


PRINT: 
PROCEDURE 
(fileSptr 
,nameSsi 
ze, requestS 
type) 
EXTERNAL; 


DECLARE 
(file$ptr 
,nameSsizc) 
ADDRESSi 


DECLARE 
requestS 
type 
BYTE; 
END 
PRINTi 


FQFSET: 
PROCF.DURE(A,ERRH) 
EXTERNAL; 
DECLARE 
(A,ERRH) 
ADDRESSi 


END 
FQFSET; 


REPORT: 
PROCEDURE 
PUBLICi 


DECLARE 
todayStype 
LITERALLY 
'100'; 
DECLARE 
yesterdayStype 
LITERALLY 
'101'; 


DECLARE 
(ptr,dummy) 
ADDRESSi 


DECLARE 
msg 
BASED 
ptr 
STRUCTURE( 


link 
ADDRESS, 


length 
ADDRESS, 
type 
BYTE, 
homeS exchange 
ADDRESS, 
response$exchange 
ADDRESS); 
DECLARE 
todaySfileSname 
(*) BYTE 
DATA(':D~:TODAYS.RPT')i 
DECLARE 
ystdaySfileSname 
C*) 
BYTE 
DATAC':D0:YSTDAY.RPT'); 


ype) ; 


ELSE 
IF 
msg.type=yesterdayStype 
THEN 


CALL 
print(.ystdaySfileSname,size(ystdaySfileSname),.msg 


•type); 
CALL 
RQSEND(msg.responseSexchange,ptr)i 
END: 
/* 
of 
do 
while 
*/ 


END: 
/* 
of 
task 
*/ 


END 
REPORT; 


ISIS-II 
FORTRAN-BB 
COMPILATION 
OF 
PROGRAM 
UNIT 
HEADER 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:PRNTMD.OBJ 
COMPILER 
INVOKED 
BY: 
FORTBB 
:Fl:PRNTMD.FRT 
DEBUG 
DATE(lB/12/7B) 
PAGEWID'rH(7B) 


SUBROUTINE 
HEADER 
C 
C-- 
CALLED 
BY 
PRINT 
TO 
OUTPUT 
REPORT 
HEADER 


C 
WRITE 
(6, 2BB) 


2BB 
FORMAT 
(, 
DATE 
TIME 
PH 
VOLUME 
TEMP 
DISSOLVED 


I'TOTAL 
'ORGANIC 
SUSPENDED 
PHOSPHATE 
INFLUENT 
EFFLUENT 
I, 


2'TURBID 
AIR 
DIS 
MIX 
INF') 
WRITE 
(6,201) 


FORMAT(44X,'QXYGEN 
CARBON 
CARBON 
SOLIDS 
CONC',6X, 


l'FLOW 
FLOW') 
WRITE(6,2B2) 
FORMAT(24X,' 
(CU.M) 
(C) 
(MG/ML) 
(I'G/ML) 
(I'G/ML) 


l' (MG/ML) 
RETURN 
END 


ISIS-II 
FORTRAN-Se 
COMPILATION 
OF 
PROGRA.M 
UNIT 
PRINT 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:PRNTMD.OBJ 


COl'PILER 
INVOKED 
BY: 
FORTSB 
:FI:PRNTMD.FRT 
DEBUG 
DATE(10/12/7B) 
PAGEWIDTH(7B) 


C 
C-- 
SUBROUTINE 
PRINT 
CALLED 
BY 
REPORT 
TO 
GENERATE 
FORMATTED 


C-- 
REPORTS. 
PRINTS 
EITHER 
TODAY'S 
FILE 
OR 
YESTERDAY'S 


C-- 
DEPENDING 
ON 
FILNM 
INPUT 
VALUE. 


SUBROUTINE 
PRINT(FILNM,TYPE) 


IMPLICIT 
LOGICAL 
(A-Z) 
CHARACTER*14 
FILNM 
INTEGER*2 
ERRFLG,RECCNT,LSTREC 


INTEGER·! 
TYPE 
INTEGER·l 
INDEX 


SINCLUDE(:Fl:EQUIV.DEC) 


CHARACTER 
BUFFER*57,PARAMS(57)*1 
REAL 
PH,VOLUME,TEMP,DISOXY,TOTCAR,ORGCAR 


REAL 
SUSSOL,PHOSFT,INFLOW,EFLFLO,TURBID 
INTEGER*1 
DIGDAT 
INTEGER*2 
MONTH,DAY,YEAR,HOUR,MINUTE,SECOND 
EQUIVALENCE 
(PARAMS,BUFFER) 


EQUIVALENCE 
(PARAMS,PH) 
EQUIVALENCE 
(PARAMS(S) 
,VOLUME) 
EQUIVALENCE 
(PARAMS(9),TEMP) 
EQUIVALENCE 
(PARAMS(13) 
,DISOXY) 
EQUIVALENCE 
(PARAMS(17),TOTCAR) 
EQUIVALENCE 
(PARAMS(21) 
,ORGCAR) 
EQUIVALENCE 
(PARAMS(2S),SUSSOL) 
EQUIVALENCE 
(PARAMS 
(29) ,PHOSFT) 
EQUIVALENCE 
(PARAMS(33),INFLDW) 
~g~i~~t~~~~ 
~~~~~~~~~i~:~~~~fg~ 
EQUIVALENCE 
(PARAMS(45),DIGDAT) 


EQUIVALENCE 
(PARAMS(46) 
,MONTH) 
EQUIVALENCE 
(PAR,h.MS{48) 
,OAY~ 
EQUIVALENCE 
(PARAMS(S0) 
,YEAR) 
EQUIVALENCE 
(PARAMS(S2) 
,HOUR) 
EQUIVALENCE 
(PARAMS 
(54) ,MINUTE) 
EQUIVALENCE 
(PARAMS(55) 
,SECOND) 


CHARACTER·3 
AIR,MIX,INFLNT,DISCHG 


COMMON 
/LSTREC/ 
LSTREC 


C 
C-- 
INITIALIZE 
RECORD 
COUNT 


C 


c 
C-- 
INITIALIZE 
INO~X 


C 


C 
C-- 
OUTPUT 
HEPDER 


C 


C-- 
C 
37 
1 
38@ 


39 
lB 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 


63 
64 
65 
66 
67 
68 
69 
~~ fW'. 
72 
~ 


73 
74 
75 
76 
77 
78 
79 
80 
81 
82 


IF(TYPE.EQ.100) 
CALL 
LOCK(2) 
OPEN(8,FILE=FILNM,STATUS='OLD' 
,IOSTAT=ERRFLG, 


lERR=9000,ACCESS='DIRECT',RECL=57) 
READ(8,REC=RECCNT,IOSTAT=ERRFLG,ERR=9100) 
BUFFER 


RECCNT=RECCNT+l 
IF( (DIGOAT.AND.101H) 
.EQ.101H) 
THEN 
AIR=' 
ON' 
ELSE 
AIR='OFF' 
ENDIF 
IF«DIGDAT.AND.102H) 
.EQ.102H) 
THEN 


MIX=' 
ON' 
ELSE 
MIX='OFF' 
ENDIF 
IF«DIGDAT.AND.104H).EQ.104H) 
THEN 
DISCHG=' 
ON' 
ELSE 
DISCHG='OFF' 
ENDIF 
IF(DIGDAT.AND.108H).EQ.108H) 
THEN 
INFLNT=' 
ON I 
ELSE 
INFLNT= 
I OFF' 


.ENDIF 
WRITE(6,101) 
MONTH,DAY,YEAR,HOUR,MINUTE,SECOND, 
IPH,VOLUME,TEMP,DISOXY,TOTCAR,OHGCAR,SUSSOL,PHOSFT, 
2INFLOW, 
EFLF LO, TURSI 0, AI R, 01 SeHG, 
M I X, INFLNT 


FORMAT (12, 
'/1 , 12, 1/' , 12,1 
X, I 2, , : ' , 12, 
, : • , 12, 1X, F4. 
1 ,IX, 
F9. 
2, 
ZIX, F9. 
4, IX. F9. 
4, 1X, Fa. 
3, 1X, Fa. 
3, 1X, F9. 
4, 1x. F9. 
4, IX, Fa. 
3, 1X, Fa . .'3 


-,lX,F7.3, 


ZIX, A3, 
IX, A3, 
IX, A3, 
IX, /1.3) 
C 
c-- 
CHECK 
FOR 
END 
OF 
FILE 
AND 
OTHER 
THINGS 


C 


INDEX=INDEX+l 
IF(TYPE.EQ.100) 
THEN 
IF(INDEX.LE.10) 
THEN 


IF(RECCNT.LT.LSTREC) 
THEN 
GOTO 
10 


ELSE 
CLOSE(S,IOSTAT=ERRFLG,ERR=920~) 
CALL 
UNLOCK(2) 


RETURN 
ENDIF 
ELSE 
INDEX=l 


gZ~E 
~~i.bgmT=ERRFLG, 
ERR=9200) 


GOTO 
1 


ENDIF 
ELSE 
IF(RECCNT.LE.288) 
THEN 
GOTO 
10 
ELSE 


83 
CLOSE(S,IOSTAT=ERRFLG,ERR=9200) 


84 
RETURN 
85 
ENDIF 


86 
ENDIF 
Cc-- 
ERROR 
HANDLERS 
C 
87 
90r0 
WRITE 
(6,9001) 
ERRFLG 
88 
900J 
FORMAT( 
'OPEN 
ERROR 
IN 
PRINT; 
I' ,14) 
89 
RETURN 


90 
9100 
WRITE(5,9101) 
ERRFLG 
9J 
91rJ 
FORMAT 
(' READ 
ERROR 
IN 
PRINT; 
I' ,14) 
92 
RETURN 


93 
9200 
WRITE 
(6.9201) 
ERRFLG 


94 
92el 
FORMAT 
('CLOSE 
ERROR 
IN 
PRINT; 
I' ,14) 
95 
RETURN 


96 
END 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MOOULE 
INITMO 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:INITMD.OBJ 


COMPILER 
INVOKED 
8Y; 
plm80 
;Fl;INITMD.plm 
DEBUG 
OATECI0/12/78) 
PAGEWIOTH(78) 


DECLARE 
sem~phore 
(3) 
ADDRESS 
EXTERNAL; 


DECLARE 
token 
(3) 
STRUCTURE 
( 
msgShdr) 
EXTERNAL; 


INIT: 
PROCEDURE 
PUBLIC; 


DECLARE 
i 
BYTE; 


2(8) 


/* 
initicalize 
semaphores 
*/ 


DO 
i=0 
TO 
2; 


CALL 
RQSEND 
(semaphore 
(i) 
, • token 
(i) 
) ; 


END; 


RETURN; 
END; 


END 
INITMD; 


LOC 
08J 
SEQ 
SOURCE 
STATEMENT 


1 
NAME 
X 2CFG 
2 
CSEG 


3 
PUBLIC 
RQRATE 


P0e0 
2e0V 
4 RQRATE; 
OW 
32 
5 
$NOLIST 


350 
$LIST 
361 
$NOGEN 
~0M 
302 
NTASK 
SET 
00e0 
)()) 
NEXCH 
SET 
?'V00 
31i4 NDEV 
SET 


0000 
365 
NCONT 
SET 
366 
3':)7 
8UILO 
INITIAL 
TASK 
TA~LE 


308 
309 
STO 
RQADBG,64,129,RQWAKE 
426 
STO 
ROTHDI,36,112,RQQUTX 
483 
STO 
RQPDSK,~8,129,RQDSKX 
540 
STO 
RQPDIR,48,130,RQDIRX 


597 
STD 
RQPDEL,64,131,RQOELX 


654 
STD 
RQPRNM,64,132,RORNMX 


711 
STO 
RQAIH,34,133,RQAIEX 
768 
EXTRN 
RQHOl 


769 
CONSTD 
CNTROL,RQHDl,80,CNSTK,81,CONTEX 


882 
STO 
TIMER,64,20,O 
939 
STO 
TIMUPD,64,1~0,0 
99 f) 
STO 
TIMER5,64,141,0 
1053 
STO 
STSINP,64,142,0 
111e 
STO 
CHANG 
E ,64 , 14 3 ,e 
1167 /~ 


STD 
REPORT,800,144,e,18 
1224 
STD 
SCAN,800, 
144,0,18 


1781 
1282 
ALLOCATE 
TASK 
DESCRIPTORS 


1283 
12B4 
GENTD 


1288 
1289 
ALLOCATE 
EXCHANGES 
129~ 
1291 
XCH 
CONTE X 
1295 
XCH 
FQ0LOK 


2·71 
AFN·01931A 


1299 
@ 
INTXCH 
RQL5EX 
1305 
1306 
BUILD 
INITIAL 
EXCHANGE 
TABLE 
1307 
1308 
XCHADR 
RQDSKX 
1315 
XCHADR 
RQDIRX 
1322 
XCHADR 
RQRNMX 
1329 
XCHADR 
RQDELX 
1336 
XCHADR 
RQAIEX 
1343 
PUBXCH 
CONTEX 
1350 @ 
PUBXCH 
RQL5EX 
1357 
PUBXCH 
FQ0LOK 
1364 
XCHADR 
RQINPX 


LOC 
OBJ 
SEQ 
SOURCE 
STATEMENT 


1371 
XCHADR 
RQOUTX 
1378 
XCHADR 
RQDBUG 
1385 
XCHADR 
RQWAKE 
1392 
XCHADR 
RQALRM 
1399 
XCHADR 
RQL6EX 
1406 
XCHADR 
RQL 7EX 
1413 
XCHADR 
STSLOK 
1420 
XCHADR 
SETLOK 
1427 
XCHADR 
DSKLOK 
1434 
XCHADR 
BMPTIM 
1441 
XCHADR 
TIMPOL 
1448 
XCHADR 
PRTREQ 
1455 
XCHADR 
CHRESP 
1462 
XCHADR 
ANRESP 
1469 
XCHADR 
MIN5EX 
1476 
XCHADR 
TIME EX 
1483 
XCHADR 
RDRESP 
1490 
1491 
BUILD 
CREATE 
TABLE 
1492 
1493 
CRTAB 
1500 
1501 
BUILD 
DEVICE 
CONFIGURATION 
TABLE 
1502 
1503 
DCT 
D0,"',0,0 
1544 
DCT 
D1,0,0,1 
1585 
1586 
BUILD 
CONTROLLER 
SPECIFICATION 
TABLE 
1587 
1588 
CST 
~,80H,5,RQLSEX,CONTEX 
1604 
1605 
BUILD 
BUFFER 
ALLOCATION 
BLOCK 
1606 
1607 
BAB 
3,BUFPOL 
1627 
END 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF 
MODULE 
CAMMOD 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:CAM.OBJ 
COMPILER 
INVOKED 
BY: 
plm80 
:Fl:CAM.plm 
DEBUG 
DATE(10/12/78) 
PAGEWIDTH(78) 


1 
DECLARE 
CN$STK 
(80) 
BYTE 
PUBLIC; 


~ 
/* 
DFS 
INTERNAL 
BUFFER 
SPACE 
*/ 


DECLARE 
RQDBUF 
(700) 
BYTE 
PUBLIC; 


/* 
DFS 
STATIC 
BUFFER 
POOL 
*/ 
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INTRODUCTION 
Companies seeking to develop microcomputer appli- 
cations are faced with two significant problems. First, 
applications are growing more and more sophisticated. 
With competition always present, products are con- 
tinually being enhanced with new features. This bur- 
dens the underlying computer system by increasing 
both the complexity of the software and the number of 
events and functions that must be handled by the 
system. 


The second problem is a management problem. These 
newer and more sophisticated 
application 
systems 


must be developed quickly in order to hit shrinking 
market windows. Also, they must be developed with 
lower manpower costs to be feasible in an engineering 
community struck by insufficient technical personnel 
and skyrocketing software development costs. 


These are the needs addressed by the iRMX 86™ Oper- 
ating System. The two goals in the development of this 
product have been power/flexibility to meet the needs 
of increasingly complex application systems, and ease 
of understanding and use, to boost the productivity of 
available engineering resources. Users of Intel's line of 
iSBC 86™Single Board Computers or custom-designed 
8086-based boards can now obtain the same benefits 
from Intel supplied system software as they can from 
Intel supplied system hardware. 


The reader of this application note is provided with 
information in four subject areas. 


• 
The requirements 
of operating 
systems 
are 


discussed along with traditional solutions. 
• 
The iRMX 86 Operating System is introduced 
and its features are discussed in relation to the 
requirements studied earlier. 
• 
System design using the iRMX 86 Operating 
System is studied using example solutions. 
• 
Code for two example systems is examined to 
learn the details of system implementation. 


Some of the topics in this note may not be of interest 
to all readers. For example, an experienced real-time 
programmer may not need to read the entire overview 
of real-time systems. For those who want to brush up 
on a few topics, the overview is organized to allow the 
reader to focus attention on areas of specific interest. 


Throughout this application note, various terms and 
concepts are introduced 
and discussed. If further 


information 
on any of these topics is desired, the 
references listed in the front of this note should be 
used. 


This overview is provided to investigate both the prob- 
lems encountered in the design of applications soft- 
ware and also the classical solutions to these problems. 


Multitasking 


A real-time system is .defined to be a system that 
reacts to events occurring external to the computer 
and which monitors or controls these events as they 
occur (or in "real-time"). The converse of a real-time 
system is known as a batch system where the outcome 
of a program does not depend on when it is run (for 
example, a payroll program). 


Two other characteristics 
typically encountered in a 


real-time system are asynchronous event occurrences 
and concurrent 
activity. The first 
characteristic 
is 


caused by events occurring randomly rather than at 
scheduled intervals. 
The second characteristic, 
con- 
current activity, takes place when two or more events 
occur nearly at the same time, requiring simultaneous 
activity. 


One method of dealing with the requirements 
of a 


real-time system would be to write a program that 
knows 
what 
events 
could 
potentially 
occur 
(for 


example, an interrupt 
occurrence, a real-time clock 


counting 
down to zero, a byte in memory being 


modified by another program). This program could 
then execute a large loop checking for the occurrence 
of these events. 


There are several problems with this approach. While 
processing one event which has occurred, the program 
is 
not 
responsive 
to 
other 
events. 
Also, 
the 


programmer has no way of prioritizing the importance 
of the various events. From a maintenance standpoint, 
this program is complex and difficult to enhance or 
modify. 


The traditional solution to these problems is a tech- 
nique called multitasking. 
Essentially, this involves 


writing many small routines instead of one large one. 
Each of these routines (tasks) can process events in- 
dependent of the other tasks in the system. In addi- 
tion, a priority can be assigned each task so that the 
operating system can decide as to which task is the 
most important 
when more than one task requests 
control of the CPU. 


The support 
for multitasking 
involves a scheduler 


which is part of the service provided by the operating 
system. The scheduler allows each task to execute its 
program as if it has sole control of the CPU, ensuring 
that all tasks desiring CPU time are serviced according 
to the priority associated with each task. 


From the standpoint 
of system design, multitasking 


has many desirable qualities. Large and potentially 
complex application programs can be decomposed into 
smaller more manageable units. This makes feasible 
the use of programmer teams to implement the appli- 
cation. Perhaps even more importantly, the potential- 
ly overwhelming problems surrounding concurrent exe- 
cution and interrupt 
handling become transparent 
to 


the 
application 
programmer. 
Also, 
multitasking 


makes the modification 
of existing tasks and the 


addition of new ones become a manageable objective 
since the interaction between tasks is minimized. 


Interrupt Handling 


A common event in a real-time system is the occur- 
rence of an interrupt. 
Because this event is so com- 


mon, an important 
feature of a real-time operating 


system is its interrupt processing capabilities. 


From the standpoint of application software, interrupt 
handling can be cumbersome. The currently running 
task must be preempted, 
various hardware 
devices 


must be manipulated and perhaps a hardware inter- 
rupt controller must be dealt with. 


A real-time operating system can abstract the occur- 
rence of an interrupt 
into something more consistent 


with the way other events are handled. A task can 
simply inform the scheduler that it does not require 
any CPU time until an interrupt 
occurs. The relative 


priority of different interrupts can also be handled in 
the same manner as the priority of multiple tasks are 
handled. Thus, the application programmer need only 
deal with the actual processing related to interrupt 
occurrence. 


Reliability 


Reliability is a keyword in all real-time systems. In 
this type of system, reliability does not refer to mean 
time between failure. In fact, the software in a real- 
time application typically cannot be allowed to fail. 
The difficulty imposed on the software by the en- 
vironment comes from the near infinite number of 
permutations that can occur. A system that appears to 
be fully debugged can fail in the field because of a 
combination 
of 
simultaneous 
events 
that 
never 


occurred before. 


The only means to avoid failure in these instances is 
through 
the use of a consistent, 
well-thought-out 


model for handling events. Any special-cased solution 
is subject to failure when the special cases that were 
designed for are violated in the real world. 


Error handling can also add reliability to an appli- 
cation 
system. 
When 
the 
application 
software 
is 


unable to anticipate the outcome of certain conditions, 
or the software has undiscovered bugs, it is vital for 
the operating system to gracefully handle the situation 
and allow for further processing to continue as best as 
possible. 


110Handling 


Many applications for 16-bit microcomputers require a 
variety of I/O devices. The support for I/O opera- 
tions on these devices is typically provided by the 
operating system. Both sequential access and random 
access devices are typically encountered and, in addi- 
tion, flexibility in handling I/O requests and acknowl- 
edgements is important. 


The flexibility necessary typically involves the sched- 
uling of a task's execution after an I/O request has been 
made. The greatest flexibility can be obtained by an 
asynchronous I/O system. In this system, a task makes 
an I/O request by calling the operating system. Once 
the processing of the request has begun, control is 
returned to the calling task. 


In this manner, the task can continue executing its 
program while the I/O operation is progressing. When 
the results of the operation are desired, the task can 
call the operating system again to wait for the com- 
pletion of the previous 1/0 request. 


The second type of I/O support is less flexible but also 
easier to use. An operating system that supports syn- 
chronous I/O allows a task to make a single operating 
system call to make an I/O request. Once control is 
returned 
to the calling task, 
the I/O operation 
is 


complete and the results are immediately available. 
This type of I/O support sometimes takes advantage of 
a technique known as autobuffering 
to regain some of 


the performance 
advantage 
of the overlapped 
I/O 


found in the asynchronous system. 


Debug Support 


The inherent characteristics 
of the real-time environ- 
ment sometimes make it difficult to debug new soft- 
ware. If the simultaneous occurrence of two events 
causes a bug in the software, detection may be difficult 
because the next time the system is run the error is not 
reproduced. Also, because of the fact that the software 
is broken down into many independent tasks, the in- 
teraction 
may be difficult to track using standard 


debugging techniques. 


The solution to these problems is a piece of software 
called the system debugger. The debugger typically 
has three characteristics. 


1) It is designed to interact with the operating system 


and therefore has intimate knowledge of code, data 
structures and system objects. 
2)Bince 
the debugger is just 
another 
task in the 


system, it does not affect the operation of the other 
tasks that are running. 


3) Through 
the use of sophisticated 
breakpointing 


facilities, the debugger allows the designer to track 
the tasks in the system, investigate their interac- 
tion with other tasks and selectively stop one or 
more tasks without stopping the entire system. 


Multiprogramming 


In some application systems, there arises the require- 
ment to run several "applications" on the computer at 
the same time. This may be due to the desire to 
squeeze more use out of the hardware or it may be due 
to some system design consideration. These separate 
"applications" (often termed jobs) share many system 
resources (especially the CPU) but at the same time 
they need to be protected as much as possible from 
other jobs. In essence, it should be possible to develop 
two jobs independently and then run them both on the 
same hardware without any interaction. If interaction 
is desired, the operating system should support some 
well-defined protocol for jobs to use to communicate. 


Free Space Management 
One of the most important resources in the computer 
system is the memory. In some applications, 
the 
amount of memory needed can be determined when 
the system is designed. In the more general case, the 
amount of memory needed by the system fluctuates. 
One solution to this management problem is to have 
available the amount needed in the worst possible 
case. A more flexible and economical solution is to 
dynamically allocate memory from a central pool upon 
demand and return 
it when possible. This service 
provides two tangible advantages. First, total memory 
needs are reduced. Second, this service allows for ease 
of use by the application programmer because there is 
no need to set aside blocks of memory and implement 
code to maintain information about current usage. 


File Management 


The ability to easily store and retrieve data stored on 
mass storage devices is a requirement in many appli- 
cation systems. Devices such as disks, tapes and bubble 
memories are used to store program code, data files 
and parameter tables. The operating system is called 
upon to store and retrieve the data and organize it 
such that application programs can easily find and 
manipulate the data when necessary. 


Typically, this service is provided through the use of a 
file system. The mass storage device is partitioned into 
blocks and logical addresses are assigned to the blocks. 
Files are created to serve as directories where the 
names of other files can be cataloged and looked up. 


In many systems, the directory structure can go many 
levels deep (see Figure 1). This provides several advan- 
tages. Directory searches can be done much faster if 
the general area where a file exists is known. Also, if 
several jobs are running at the same time, each can be 
given its own directory and therefore isolated from the 
others. Lastly, for human users, it is much easier to 
manage the information on the disk when some logical 
structure of files exists. 


De~celndependence 


One of the unfortunate characteristics of I/O devices is 
that they all tend to present different interfaces to the 
system software. When this is the case, the application 
programmer must become familiar with the unique 
characteristics of each device in order to communicate 
with it. One solution is to create an I/O driver which 
does the actual 1/0. This driver can then be called by 
the 
application 
program 
whenever 
communication 


with the device is desired. 


The problem with this solution is that the programmer 
must still know what type of device is being talked to 
since the I/O driver is specialized. If the system con- 
figuration 
changes, 
all of the 
software 
must 
be 


rewritten to call new device drivers. The best solution 
is to design a standard interface to device drivers and 
postpone until 
run-time 
the decision about which 


devices to use. With this type of system, an application 
program can be written assuming that at run-time the 
human or program that invokes it will provide a speci- 
fication of which devices should be used. 


High·Level Man·Machine 
Interface 


In addition to the services provided for application 
programs by the operating system, a set of services 
typically is offered to the human user sitting at the 
system console. System utilities are needed for file 
copying, disk formatting, and directory maintenance. 
Programs need to be loaded off disk to run and the 
programs 
themselves 
must 
be 
able 
to 
retrieve 


parameters 
passed to them by the operator. All of 


these functions 
are usually provided by the man- 


machine interface software in the operating system. 


Make Versus Buy 


The previous sections dealt with operating system re- 
quirements. These requirements 
are encountered in 


the application development 
process. Whether 
the 


solution to meet the needs comes from the individual 
application 
designer 
or from 
a computer 
system 


vendor, the requirements do not change. 


There usually exists a rather simple tradeoff between 
designing a custom operating 
system or buying a 


generalized system and tailoring it to the individual 
needs of the application. There are advantages to the 
custom 
solution. The system 
can often 
be made 


smaller since the requirements 
are known in great 


detail. Also, some small performance improvements 
can sometimes be made by taking advantage of the 
special cases to speed things up. 


Buying an operating system from a computer system 
vendor offers five advantages. 


1) Engineering resources are becoming scarce. The use 


of an opearting system from a vendor allows atten- 
tion to be focused on the application software. 


2) The time taken to bring the product to market can 


be shortened, thereby gaining a competitive edge 
and generating early revenue. 


3) Long-term maintenance costs can be reduced be- 


cause the vendor supports the operating system 
software. 


4) Personnel in all branches of the company can be- 


come familiar with one software architecture and 
apply this 
knowledge to a range 
of products. 


This applies not only to the design engineers, but 
also to quality assurance, customer engineers and 
system analysts. 


5) The computer system vendor has knowledge of 


future technological advances coming in the prod- 
uct lines. For this reason, the operating system can 
be constructed so that applications software can be 
transported 
to future hardware without the need 


for expensive redesign. 


In summary, the trade-offs are clear. An operating 
system from a computer system vendor is not the 
answer for every application. But in most cases, the 
most economical and safest bet is to take advantage of 
the expertise of the vendor for the system software 
and use engineering resources to more quickly solve 
the application problem. 


INTRODUCTION 
TO THE iRMX 86™ 


OPERATING SYSTEM 


The iRMX 86 Operating System meets the needs of 
real-time applications while simultaneously providing 
the full set of services normally found in a general- 
purpose operating system. 


The overall picture of the iRMX 86 Operating System 
is shown in Figure 2. The iRMX 86 Nucleus provides 


support for multitasking, 
multiprogramming, 
inter- 


task communication, 
interrupt 
handling 
and error 


checking. The Basic I/O System provides support for 
device 
independent 
and 
file 
format 
independent 
manipulation of data on 1/0 devices. The Extended 1/0 
system 
provides 
synchronous 
I/O calls, automatic 


buffering, logical file name support and high-level job 
management. 
The application 
loader provides 
the 


ability to load code and data from mass storage devices 
into RAM memory. The Human Interface provides for 
a high-level man-machine 
interface 
as well as file 
utilities and parsing support for application programs. 


The following sections deal in more detail with each of 
these iRMX86 pieces. If more information is desired on 
the features discussed, please refer to the documents 
listed in the front of this application note. 


Architecture 


The iRMX 86 architecture is an object-oriented archi- 
tecture. 
This means that 
the operating 
system is 


organized as a collection of building blocks that are 
manipulated by operators. The building blocks of the 
iRMX 86 system are called objects and are of several 
types. Some of the object types are tasks, jobs, mail- 
boxes, semaphores 
and segments. 
These types are 


explained in subsequent sections of this application 
note. 


This type of architecture 
has two major advantages. 
First, the system is easier to learn and use. The at- 
tributes of the various objects and the operations that 
can be performed on them are well defined and con- 
sistent. Once an object type is understood, all objects 
of that type are understood. 


The second advantage 
to an object-oriented 
archi- 


tecture is the ease with which the operating system 
can be tailored to the application. If there is no need 
for a given object in the application, all operators for 
that object are not included in the final configured 
system. On the other hand, if the application designer 
needs a more complex building block that is not in the 
basic system, he can define and use a new object type. 


Table 1 lists all of the system calls in the iRMX 86 
Nucleus. There are three groupings of system calls in 
this table. 


1) The general system calls apply to all objects uni- 
formly. 
2) The first two system calls for each object are the 


create and delete calls. These calls simply create a 
new object and initialize its attributes or delete an 
existing object. 


3) The remaining system calls are specific to the at- 


tributes of a particular object. With this organiza- 
tion in mind, the entire operation of the iRMX 86 
nucleus can be glimpsed in a single table. 


Tasks 


Tasks are the active objects in the iRMX 86 archi- 
tecture. Tasks execute program code and therefore are 
the only objects that can manipulate other objects. The 
attributes of a task include its program counter, stack, 
priority and dispatcher state. 


Tasks compete with each other for CPU time and the 
iRMX86 scheduler determines which task to run based 
upon priorities. The dispatcher states for an iRMX 86 
task are shown in Figure 3. At any given point in time, 
the highest priority 
task that 
is ready to run has 


control of the CPU. Control is transferred 
to another 


task only when 
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Figure 3. Task State Transition 
Diagram 


1) the running task makes a request that cannot im- 


mediately be filled and is, therefore, moved to the 
asleep state, 
2) an interrupt occurs causing a higher-priority task to 


become ready to run or 
3) the running 
task causes a higher-priority 
asleep 


task to become ready by releasing some resource. 


The 
suspended 
and 
asleep-suspended 
states 
are 


entered whenever the suspend system call is invoked 
for a particular task. 


Job and Free Space Management 
Support for multiprogramming 
is provided by the job 


object. A job provides the environment 
for tasks to 


execute their programs. All other objects needed for a 
particular 
application are contained within the job. 


System 
Calls 
for 
O.S. Objects 
Attributes 
Object·Specific 


All Objects 
System 
Calls 


JOBS 
Tasks 
CREATE$JOB 


Memory pool 
DELETE$JOB 


Object directory 
SET$POOL$M IN 


Exception 
handler 
GET$POOL$ATIRIB 
OFFSPRING 


TASKS 
Priority 
CREATE$TASK 


Stack 
DELETE$TASK 


Code 
SUSPEND$TASK 


State 
RESUME$TASK 


Exception 
handler 
GET$EXCEPTION$HANDLER 
SET$EXCEPTION$HANDLER 
CAT ALOG$OBJ ECT 
SLEEP 
GET$TASK$TOKENS 
UNCATALOG$OBJECT 
GET$PRIORITY 
SET$PRIORITY 


LOOKUP$OBJ ECT 
SEGMENTS 
Buffer with length 
CREATE$SEGMENT 
DELETE$SEGMENT 
ENABLE$DELETION 
GET$SIZE 


MAILBOXES 
List of objects 
CREATE$MAILBOX 
DISABLE$DELETION 
List of tasks waiting 
for objects 
DELETE$MAILBOX 
SEND$MESSAGE 
FORCE$DELETE 
RECEIVE$MESSAGE 


GET$TYPE 
SEMAPHORES 
Semaphore 
unit value 
CREATE$SEMAPHORE 


List of tasks waiting 
for units 
DELETE$SEMAPHORE 
RECEIVE$UNITS 
SEND$UNITS 


REGIONS 
List of tasks waiting 
for critical 
CREATE$REGION 


section 
DELETE$REG ION 
RECEIVE$CONTROL 
ACCEPT$CONTROL 
SEND$CONTROL 


USER 
License rights to a given extension 
CREATE$EXTENSION 


OBJECTS 
type 
DELETE$EXTENSION 


New object 
template 
CREATE$COM POSITE 
DELETE$COMPOSITE 
INSPECT$COMPOSITE 
ALTER$COMPOSITE 


A specific attribute 
of the job is a free memory pool 


from which blocks can be allocated 
only by tasks 
within the job. Also, the job contains an object direc- 
tory which can be used by tasks to catalog objects 
under ASCII names so that other tasks, knowing the 
ASCII name, can look up the object and thereby gain 
addressability 
to it. 


More than one job can co-exist in the computer system. 
Tasks within jobs can also create children jobs forming 
a hierarchical 
tree of jobs (see Figure 4). Each job in 


the system has its unique set of contained objects, its 
own memory pool and its own object directory. 


Segments 


A fundamental 
resource that 
tasks need is memory. 
Memory 
is allocated 
to tasks 
in the 
form 
of the 


segment object. The segment is a block of contiguous 
memory. 
The attributes 
of a segment 
are its base 


address and size. A task needing memory requests 
a 


segment 
of whatever 
size it requires. 
The Nucleus 


attempts 
to create a segment 
from the memory pool 


given to the task's job when the job was created. 


If there is not enough memory available, the Nucleus 
will try to get the needed memory from ancestors of 
the job. 


Communication 
and Synchronization 


In many cases it is necessary for two tasks to com- 
municate in order to exchange data and commands. 
This is supported through the use of an object known 
as a mailbox. As its name implies, a mailbox is a 
holding place for objects. One task can send an object 
to a mailbox, causing the object to be queued there. 
Another task can later receive an object from the mail- 
box and thereby gain access to it (see Figure 5). If a 
task tries to receive an object from a mailbox and there 
are no objects there, the task can optionally be made to 
sleep for a specified time for an object to appear. 


Note that any object can be sent to a mailbox to be 
received by another task. Typically, the object sent is a 
segment which is a block of memory and can contain 
any commands or data. The term message is often used 
to describe the object during the time it is being sent 
through a mailbox. 


In those cases where there is a requirement 
for syn- 


chronization between tasks but no data need be sent, a 
simpler more efficient mechanism exists. The sem- 
aphore object provides for the allocation of abstract 
entities 
called units. The primary 
attribute 
of the 
semaphore is an integer number. Tasks may send units 
to a semaphore thereby increasing the integer number 
or they can request 
units, 
thereby 
decreasing the 


number. If a task makes a request for more units than 
are available, it can optionally be made to sleep for a 
specified amount of time. This mechanism can be used 
for synchronization, 
resource allocation and mutual 


exclusion. 


Interrupt Management 


When an interrupt is sensed by the 8086 hardware, a 
user interrupt 
handler 
is executed. The interrupt 


handler can either perform all interrupt 
processing 


itself without making any iRMX 86 system calls, or it 
can signal an interrupt 
task allowing more general 


interrupt 
processing including calls to the operating 
system. 


The operating system maps hardware interrupt priori- 
ties into the software priority scheme allowing the 
designer to specify what software functions are im- 
portant enough to have some interrupt levels masked 
off during their execution. Although this mapping 
should always be kept in mind during design, the 
mechanics 
of dealing 
with 
interrupt 
control 
are 


handled by the operating system. 


Error Management 


One of the central themes in the design of the iRMX 
86 operating system has been reliability. The results of 
these efforts are evident in two particular features of 
the architecture. 
Beyond the ease of understanding 


brought about by the symmetry of the system, the 
reliability of applications using the iRMX 86 software 
is increased. 


The general case (as opposed to checking only for 
specific combinations of errors) has been designed for. 
Because of this, an unexpected combination of events 
or the simultaneous 
occurrence 
of interrupts 
will 


never catch the system by surprise. 


In the event that errors do occur, the operating system 
is set to detect them. Virtually all parameters in calls 
to the operating system are checked for validity. Any 
inconsistency causes a jump to an error routine to 
handle the problem. Two types of errors can poten- 
tially occur and there are two ways of handling errors. 


The first error type is the programmer error condition 
which comes about due to some mistake in the coding 
of a system call. The second type is an environmental 
condition which arises due to factors out of the control 
of the engineer (e.g. insufficient 
memory). Each of 


these error types can be handled in-line by checking a 
status code upon return from the call or can cause an 
error handling subroutine to be called by the system. 
The system designer can choose the desired method for 
the system, for a specific job, and even for individual 
tasks within a job. 


Asynchronous 1/0 


Asynchronous 
I/O 
system 
calls 
are 
provided 
to 
support device independent I/O to any device in the 


system. The type of I/O and the type of device are 
interrelated 
as shown in Figure 6. Every device driver 
in the I/O system is required 
to s,upport a standard 
interface. In this manner, all devices look the same to 
higher 
level 
software. 
In 
the 
same 
manner, 
the 
individual 
file drivers, 
which provide 
the different 
types of file systems, all have a standard interface and 
call upon the various device drivers to perform 
I/O. 
These interface standards 


1) provide for the device independence 
in. the higher 
layers of the I/O system 


2) make it easier for Intel to add future device drivers 


as new devices become available and 


3) make it possible for iRMX 86 users to add their own 
drivers for custom I/O devices. 


The iRMX 86 I/O system provides both asynchronous 
and synchronous 
system calls. The asynchronous 
110 


calls 
are 
faster, 
provide 
'more 
flexibility 
in 
the 


selection of options and allow the program making the 
call to perform other functions while waiting for the 
I/O operation to complete. 


The method by which the 110 system responds to the 
requestor 
is through 
the use of a mailbox. When any 


call is made to the asynchronous I/O system, one of the 
parameters 
indicates 
a mailbox 
where 
the 
caller 


expects to receive a segffient containing the results of 
the operation (see Figure 7). 


Synchronous 1/0 


The alternative 
to using the asynchronous 
110 system 


is to use synchronous 
I/O system calls. As shown in 
Figure 8, the number 
of options available are fewer 


and the caller cannot 
continue 
execution 
until 
the 


entire I/O operation is completed but from an ease-of- 
use standpoint, 
the situation is much simplified. 


Response$mailbox$token 
= RQ$create$ 
mailbox (0, @status); 
CALL RQ$A$read(connection$token, 
buf$ptr, 


count, response$mailbox$token, 
@status); 


IORS$token = RQ$receive$message 
(response$mai Ibox$token, 0FFFFH, 
@resp$t, @status); 
{check status} 
Call RQ$delete$segment(IORS$token, 


@status); 


Call RQ$S$read(connection$token,buf$ptr, 


count, @status); 
jcheck status} 


Figure 8. Synchronous 
1/0 Call 


Two other 
features 
provided 
by the Extended 
I/O 
System are logical name support 
and autobuffering. 


Logical names allow the application 
designer to post- 
pone the decision concerning 
which files to use until 
run-time. Essentially, 
all programs can be written and 
compiled 
using 
logical 
file names 
and 
then 
these 


logical names can be mapped into real file names at 
run-time. 


The use of autobuffering 
regains much of performance 
advantage offered by overlapped I/O. When a user task 
opens a file for input, one or more buffers are auto- 
matically 
created and filled with data from the file. 


Thus, when the user task makes an I/O request, 
the 
data may already be available in memory. A similar 
case exists for write requests 
in that the I/O system 
will buffer data to be written to a device, allowing the 
user task to continue on.. 


Loaders 


The iRMX 86 application 
loader and bootstrap 
loader 
perform 
a variety 
of services for the user software. 


The following is a brief 
summary 
of the available 
features. 


1) Systems 
can be boot loaded 
from mass 
storage 
devices at system reset. This saves not only ROM or 
EPROM memory, 
but also reduces 
field mainte- 
nance costs by allowing easy field updates. 


2) Users can design 
their 
own SYSGEN 
procedure 


allowing tailoring 
of an application 
system to the 
individual installation. 
3) Infrequently 
used programs can be brought in from 
mass storage when needed instead of using system 
memory unnecessarily. 


File Management 
There are three types of files supported by the iRMX 
86 I/O system, named files, physical files and stream 
files. Named files are supported on devices possessing 
mass storage capability. Files in this system have 
ASCII pathnames 
and are cataloged in directories. 


Each device in the system contains a directory tree as 
shown previously in Figure 1. Access protection is 
provided through the use of access lists for each file. 
Each user or group of users in the system can be given 
different types of access to the file or can be denied 
access to it. 


For devices that cannot support a named file structure 
(e.g. printers and terminals) the physical file driver is 
used. Devices in this category are treated strictly as 
data going into and/or out of the device. If it is 
desirable to treat a mass storage device strictly as a 
large mass of data, it can also be addressed through 
the physical file driver. 


The third type of file is the stream file. This file type 
has no correlation with any physical device but rather 
uses system memory for temporary storage of data. An 
example of the usage of a stream file is a job that gets 
its input stream of data from a file. Depending on 
which time the job is run, this file might be a named 
file on disk, a terminal, or a stream file being written 
to by another job (see Figure 9). 
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Human Interface Subsystem 


The highest level of support provided by the iRMX 86 
Operating System is the Human Interface Subsystem. 
This piece of software provides two basic services. 
Programs can be invoked by typing the program name 
at the system console. The Human Interface will load 
the given program into memory, set it up as a job and 
start it running. The invoked program can then call 
upon the Human Interface routines to determine what 
parameters were passed to it as part of the operator 
input. 


The Human Interface also contains a set of system 
utility routines which are used to copy files and disks, 
format disks, dynamically alter the system configura- 
tion and others. 


Debugging Subsystem 


The iRMX 86 Debugging Subsystem allows the de- 
signer to interact with the prototype system and iso- 
late and correct program errors. Since the debugger is 
an object-oriented debugger and is aware of the in- 
ternal structure of the operating system, it can provide 
detailed information concerning objects and can mon- 
itor mailboxes and semaphores providing a breakpoint 
facility as well as error detection. 


Specifically, 
the 
iRMX 86 
Debugging 
Subsystem 


provides six sets of functions: 


1) Wake-up upon operator invocation. The operator 


types a control-D key to cause the debugger to 
wakeup. 


2) View system lists. The debugger can view lists of 


objects either globally or specifically for a given 
job. Also, lists of objects and tasks queued at mail- 
boxes and semaphores can be seen. 


3) Inspect objects. A detailed report on any object can 


be requested 
showing 
the 
current 
state 
of all 


relevant attributes. 


4) Inspect and modify memory. 
5) Breakpoint 
control. Any number of breakpoints 


can be set causing a single task to break on either 
execution of particular 
instructions 
or sends and 


receives of messages or units. 


6) Error handling. The debugger can be set up to be 


the system 
default 
error handler 
thus catching 


system exceptions. 


Configuration and Initialization 


Once the 
application 
is designed 
and coded, the 


engineer needs a mechanism to inform the operating 
system of the software and hardware configuration. 
Essentially, this involves building tables of informa- 
tion using tools provided with the iRMX86 product. 


As shown earlier in Figure 4, the jobs in an iRMX 86 
system form a hierarchical tree. The root in every job 
tree is known as the root job and is supplied as part of 
the iRMX 86 system. There are three important 
fea- 


tures of this job. 


1) The root job has an object directory for cataloging 


and looking up objects. The special feature of this 
directory is that is is accessible by all tasks in the 
system since everyone can address the root job. For 
this reason the root object directory is useful for 
setting up inter-job communication paths. 


2) The root job initially contains all free space in the 
system. Part of the system initialization 
code per- 
forms a memory scan to automatically 
determine 
the 
amount 
of free 
RAM in the 
system. 
This 
memory is put into the free space pool of the root 
job and parceled out as user jobs are created. 
3) The root job contains only one task, the root task. 
This task scans the configuration 
tables generated 
by the user and creates the user-specified jobs. 


Examples 
of 
configuration, 
initialization 
and 
the 


LINK 86 and LOC 86 operations needed to generate a 
system will be presented in the Code Examples section. 


This section describes the design process involved in 
using the iRMX 86 system to solve application 
prob- 


lems and presents two example solutions. 


System design with the iRMX 86 Operating 
System 


should be viewed as a process starting with the highest 
level definition 
of system requirements 
and succes- 


sively .adding 
more detail 
until 
the end product 
is 


program code. This description 
sounds very much like 


the description 
of top-down design and, of course, it 


should. 
This 
methodology 
offers 
not 
only 
quicker 


designs, fewer design flaws and easier implementation, 
but also easier maintenance 
and enhancement. 


In general, every iRMX 86 design progresses through 
the following steps: 


1) Define system requirements. 
2) Breakdown into highest level sub-functions Gobs). 
3) Define job functions. 
4) Determine inter-job command and data flow. 
5) Break down each job into sub-functions. 
6) Based upon requirements, 
assign tasks to perform 


job functions. 


7) Determine inter-task command and data flow. 
8) Write program code for each task. 


Step 8 becomes the design process associated with the 
application 
programs 
themselves. 
The code for each 


task is essentially a sequential program that performs 
one of the functions of the computer system. Standard 
techniques 
for top-down design can therefore be used 


here to specify each module and its inputs and outputs 
as well as global and local data structures 
etc. The end 


product of this procedure is a modularized application 
system that should be easy to debug. 


APPLICATION 
EXAMPLE 1 


The first example presented 
here is based on the dis- 


tributed local network diagrammed 
in Figure 10. Each 


workstation 
shown is an intelligent 
terminal 
having 


local data and program 
storage. The stations 
all use 


the File Sharing Node (FSN) for storage and retrieval 
of records in much the same way as the secretaries 
in 
an office would make use of a filing cabinet. The FSN 
maintains the files on a fixed disk device and responds 
to requests 
from the workstations 
for access to the 


data. The design to follow concentrates 
on the File 


Sharing Node. 


System Requirements 


Each intelligent terminal in the network has command 
processing 
software. 
When a file reference 
is made 


that 
cannot 
be satisfied 
by the local file system, 
a 


request is made to the File Sharing Node. This request 
consists of a log-on request followed by a string of IJO 
requests and ultimately a log-off request. 


The number 
of intelligent 
terminals 
(workstations) 


hooked up to the FSN varies 
from installation 
to 


installation. 
Therefore, 
the FSN must be capable of 
handling many simultaneous 
requests and no assump- 
tions can be made about 
the maximum 
number 
of 
workstations or requests that may need to be handled. 


Each node in the network 
has a unique address. 
A 


packet is sent onto the network by one node and the 
address field is examined by all other nodes. If this 
field does not match the node's address the packet is 
ignored. If a match is found the packet is retrieved 
from the network. 


Hardware Requirements 


The three main hardware 
building blocks needed by 


this application 
are shown in Figure 
11. The iSBC 


86112A Single 
Board 
Computer 
will communicate 


with the iSBC 544 Intelligent 
Communications 
Con- 
troller to establish and maintain communications 
with 
the network. The Intel 8085A on the iSBC 544 board 
will perform all of the address recognition, 
acknowl- 


edgements, 
packet retrieval 
and packet 
transmittal. 


The iSBC 206 Hard Disk Controller 
will be used to 


create, maintain and access the data files which are at 
the heart of this application. 


System Design 


The first step in the system design process is the 
breakdown of the system functions into one or several 
jobs. The reasons for doing this are system modularity 
and protection. With this type of design, each job can 
be designed separately, perhaps even by a different 
engineer or engineering team. The input and output 
requirements will be specified very tightly and the job 
will take on the appearance of a black box to other jobs 
in the system. If the job is enhanced or modified at a 
later date, the rest of the system can be left undis- 
turbed providing that the input and output response 
remains the same. 


The job object in the iRMX 86 operating system also 
affords a degree of software protection for the tasks 
and other objects contained within the job. Each job 
has 
a separate 
memory 
pool, a separate 
object 


directory and a separate 
identification 
to the I/O 


system. 


The two primary groupings of functions in this appli- 
cation are those related to the network communica- 
tions and those related to processing the file trans- 
action request. A list of a possible split-up of system 
functions is shown in Figure 12. 


COMMUNICA 
nONS 
JOB 
FILE 
TRANSACTION 
JOB 


• ISBC 
544'" 
INPUT 
INTERRUPT 
• RETRIEVE 
INPUT 
REQUEST 


SERVICE 
PACKETS 
FOR 
SERVICING 


• iSBC 544'" 
OUTPUT 
INTERRUPT 
• DETERMINE 
WORKSTATION 


SERVICE 
STATUS 


• SERVICE 
OUTPUT 
REQUEST 
• SERVICE 
TRANSACTION 


MAILBOX 
REQUESTS 


• QUEUE 
PACKETS 
OF,INPUT 
DATA' 
PERFORM 
LOG·ON 
AND 
LOG·OFF 


AT INPUT 
MAILBOX 
FUNCTIONS 


The communication between the file transaction job 
and the communication job must fulfill two basic 
needs. The communication job will receive interrupts 
when packets addressed 
to the FSN are received. 


In order to remain attentive to new requests coming 
in, the communications job should have the capability 
to "spool" the requests off to the file transaction job. 
This buffering can be provided by using the mailbox 
object. Segments can be created to contain the packet 
request data and can then be sent to a mailbox where 
the file transaction job can receive and process them. 


When the file transaction job must send a packet to a 
workstation, 
the requirement 
is seen for another 


queue of requests. Since the communications board 
can only put one packet at a time on the network, a 
mailbox should be provided to allow tasks in the file 
transaction job to send output request segments into 
t!J.equeue and then continue on (seeFigure 13). 
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Since tasks in both the file transaction job and the 
communications job must have access to these input 
and output mailboxes, some means must be set up to 
"broadcast" the identifier for these objects. 


In the iRMX 86 system, each object has associated 
with it a 16-bit number called a token. Whenever an 
object is referenced in an operating system call, the 


token for the object is used. For example, assume that 
a segment must be sent to a mailbox. The segment and 
mailbox each have a token and these tokens are passed 
to 
the 
operating 
system 
as 
parameters 
in 
the 


send$message system call. 


There are three major ways to get the token for an 
object. The first way is to create an object. Whenever 
the operating 
system is called to create a new object, 


the value returned 
from the procedure call is the token 


for the new object. The second way to receive a token 
is through 
the receive message system call where an 


object is received from the queue at a mailbox where it 
was sent by another task. 


The third major mechanism for the receipt of a token 
is provided by the object directory 
concept. As men- 


tioned previously, each job in the system has an object 
directory. 


If a task in a job has the token for an object and wishes 
to let other 
tasks 
in other jobs have access to the 


object, the task can "catalog" the object in the object 
directory. 
The catalog$object 
system 
call takes 
the 


token for an object and an ASCII name as parameters 
and creates an entry in the object directory. If another 
task knows the ASCII name for an object, it can obtain 
the token by performing a lookup$object call. 


The object directory 
mechanism 
will be used in this 


example to allow the communications 
job to ''broad- 


cast" the tokens for the input and output mailboxes. 
The jobs for this application are shown in Figure 14. 


The next step of the design methodology calls for each 
job to be further 
divided into sub-functions. 
In this 


application 
note, 
only 
the 
file 
transaction 
job 
is 


studied. 


1) Retrieve input requests from the mailbox set up by 


the communication job. 


2) Determine 
state 
of specified workstation 
(for ex- 


ample, is it logged on?). 


3) Perform IJO operation or log-on or log-off. 
4) Build and send response to the workstation. 


Recall from the discussion 
of system 
requirements 


that the number of nearly simultaneous 
requests that 


may be received by the FSN is not known. For this 
reason, some mechanism 
must be provided 
to allow 


parallel 
processing 
of many 
requests. 
This 
should 


prove feasible since the performance 
of step 3 will 


involve many delays while waiting for the operating 
system to perform 1/0 operations. 


One 
straightforward 
way 
to 
provide 
for 
parallel 


processing is to create a task for each workstation 
that 


logs on. In this 
manner, 
each I/O request 
will be 


handled 
by a unique 
task. Through 
the use of the 


iRMX 86 scheduler, maximum CPU utilization will be 
gained by allowing each task to individually 
compete 


for CPU time. These "worker" tasks fulfill function 3 
and 4 for the file transaction 
job. 


Function 1 and 2 can be fulfilled by a single task. This 
task will wait at the input 
mailbox set up by the 


communications 
job. When a packet is received that 


requests 
a log-on operation, 
the "listener" 
task will 


create 
a new "worker" 
task 
to handle 
the request. 


Figure 15 shows a picture of the design. 


Figure 15. Diagram of Design of 


File Transaction 
Job 


The string 
of transaction 
requests 
that 
follow will 


simply be demultiplexed 
by the listener 
task. 
The 


workstation 
ill will be searched for and, if found, the 


packet will be sent to the appropriate 
worker task. If a 


request comes in from a station that is not logged on, 
an error response is sent directly to the communica- 
tions output 
mailbox for transmittal 
to the station 


that made the request. 


If the request packet indicates that a station desires to 
log-off, the listener task will delete all local reference 
to the station and pass the packet along. The listener 
task cannot simply delete the worker since the worker 
may be in the process of servicing a previous I/O 
request. In general, it is never a good idea to arbi- 
trarily delete another task. A better protocol is to pass 
along the message signaling the worker task to delete 
itself when convenient. 


An investigation 
of the intertask 
communications 


needs highlights 
the requirement 
for passing data 
between tasks. The interjob co=unications 
protocol 


discussed earlier specified that the listener task will 
receive input request segments from the co=unica- 
tions job via a mailbox. 


Within these segments are fields containing the work- 
station ill and the command. Based upon these fields 
one of two things happens. If the command indicates 
that the station wishes to log on, a new worker task 
must be created to process the I/O requests that will 
follow. 


The code executed by all worker tasks will be identical 
since they all perform identical functions. However, 
some unique pieces of information must be passed to a 
new worker task. This can be accomplished by having 
the worker task first wait at a "log on" mailbox. Here it 
will receive a segment from the listener task which 
contains the necessary information (see Figure 16). 
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Figure 16. Communications 
Between 
Listener 


Task and a Newly Created 
Worker Task 


After this initialization is complete, the workstation 
requests that are received by the listener task can be 
sent to the service mailbox associated with the work- 
station. The token for the service mailbox is one of the 
pieces of information contained in the log on segment. 


The last communication path needed is predefined by 
the interjob communication protocol. When either the 


listener 
task or one of the worker tasks needs to 


transmit a packet to a workstation, a segment is sent 
to the output request mailbox of the communication 
job. 


The final step in the design methodology is to write 
program code for the tasks in the system. This step is 
performed in the Code Examples section. 


APPLICATION 
EXAMPLE 2 


This example will deal with the design of a custom 
device driver for the iRMX 86 operating system. As 
shown in Figure 6, a device driver accepts high-level 
commands from the file drivers (such as read, write, 
seek, etc.) and transforms 
these commands into I/O 


port read and write commands in order to commu- 
nicate with the device itself. By studying the construc- 
tion of a driver for the iSBC 534 Serial Co=unication 
Expansion Board, a better understanding of the iRMX 
86 I/O system will be gained along with an example of 
the use of nucleus facilities to construct a higher-level 
software function. 


Overview of Device Driver Construction 


Each I/O device consists of a controller and one or 
more units. A device as a whole is identified by a 
device number. Units are identified by unit number 
and device-unit number. The unit number identifies 
the unit within the device and the device-unit number 
identifies the unit among all the units on all of the 
devices. 


A device driver must be provided for every device in 
the hardware configuration. That device driver must 
handle the I/O requests for all of the units on the 
device. Different 
devices can use different 
device 


drivers; or if they are the same kind of device, they can 
use the same device driver code. 


At its highest level, a device driver consists of four 
procedures 
which 
are 
called 
directly 
by the 
I/O 


System. These procedures can be identified according 
to purpose, as follows: 


Initialize I/O 
Finish I/O 
Queue I/O 
Cancel I/O 


When a user makes an 1/0 System call to manipulate a 
device, the I/O System ultimately calls one or more of 
these procedures, which operate in conjunction with 
an interrupt 
handler 
to coordinate 
the actual 
I/O 


transfers. This section provides a general description 
of each of these procedures, and the interrupt handler. 


INITIALIZE 
1/0 


This procedure 
creates 
all of the iRMX 86 objects 


needed by the remainder 
of the routines in the device 


driver. It typically creates an interrupt 
task and a seg- 


ment to store data local to the device. It also performs 
device initialization, 
if any such is necessary. The IJO 


System calls this routine just prior to the first attach 
of a unit on the device (the first RQ$A$PHYSICAL 
$ATTACH$DEVICE 
system call). The time sequence 


of calls to these procedures 
will be described a little 


later. 


FINISH 
1/0 


The IJO System calls this procedure after all units of 
the 
device 
have 
been 
detached 
(the 
last 
RQ$A$ 


PHYSICAL$DETACH$DEVICE 
system 
call). 
The 


finish$IO 
pr~edure 
performs 
any 
necessary 
final 


processing on the device and deletes all of the objects 
used by the device handler, 
including 
the interrupt 


task and the device-local data segment. 


QUEUE 110 


This procedure places IJO requests on a queue, so that 
they can :;;tart when the appropriate 
unit becomes 


available. 
If the 
device is not busy, 
the queue$IO 


procedure starts the request. 


CANCEL 
110 


This 
procedure 
cancels 
a 
previously 
queued 
IJO 


request. Unless the device is such that a request can 
take an indefinite 
amount of time to process (such as 


keyboard input from a terminal), 
this procedure 
can 
perform a null operation. 


INTERRUPT 
HANDLERS 
AND INTERRUPT 
TASKS 


Mter 
a device finishes processing an IJO request, 
it 


sends 
an interrupt 
to the iRMX 86 system. 
As a 


consequence, 
the interrupt 
handler 
for the device is 


called. This handler 
either 
processes 
the interrupt 


itself 
or signals 
an interrupt 
task 
to process 
the 


interrupt. 
Since an interrupt 
handler is limited in the 


types of system calls that it can make, an interrupt 
task usually services the interrupt. 
The interrupt 
task 


feeds the results 
of the interrupt 
back to the appli- 
cation software 
(data from a read operation, 
status 


from other types of operations). It then gets the next 
IJO request 
from 
the queue 
and starts 
the device 


processing this request. This cycle continues until the 
device is detached. 
The interrupt 
task 
is normally 


created by the initialize 1/0 procedure. 


The IJO System calls each one of the four device driver 
procedures in response to specific conditions. Three of 
the 
procedures 
are 
called 
under 
the 
following 


conditions. 


1) In order to start IJO processing, the user must make 


an IJO request. This can be done by making a variety 
of system calls. However, the first IJO request 
to 


each device-unit 
must be the RQ$A$PHYSICAL$ 


ATTACH$DEVICE system call. 


2) The 1/0 System 
checks to see if the IJO request 


results from the first RQ$A$PHYSICAL$ATTACH 
$DEVICE system call for the device (the first unit 
attached in a device). If it is, the 1/0 System realizes 
that the device has not been initialized and calls the 
initialize 
IJO procedure 
first, before queueing 
the 


request. 


3) Whether or not the IJO System called the initialize 


1/0 procedure, 
it calls the queue IJO procedure 
to 


queue the request for execution. 


4) The I/O System 
checks to see if the request 
just 


queued resulted from the last RQ$A$PHYSICAL$ 
DETACH$DEVICE system call for the device (de- 
taching 
the last unit of a device). If so, the IJO 


System 
calls the finish 
IJO procedure 
to do any 


final processing on the device and clean up objects 
used by the device driver routines. 


The 
I/O 
System 
calls 
the 
fourth 
device 
driver 


procedure, 
the 
cancel 
I/O 
procedure, 
under 
the 


following conditions: 


• 
If 
the 
user 
makes 
an 
RQ$A$PHYSICAL$ 


DETACH$DEVICE 
system call specifying 
the 


hard detach option, in order to forcibly detach 
the connection objects associated with a device- 
unit. 


• 
If a job containing 
the task which made the 


request is deleted. 


Each procedure will now be discussed in more detail. 
The initialize $10 procedure takes three parameters: 


The duib$p parameter 
contains a pointer to a device 


unit information 
block (DUIB) which is the configu- 


ration table for the device in question. The structure 
of 


this table is shown in Figure 17. Note that this table 
contains pointers to device and unit information 
tables 


which can contain hardware specific information (such 
as IJObase addresses, interrupt 
levels etc.). 


The second parameter 
is a pointer to a word which can 


be assigned the value of a token for an iRMX 86 object. 
Quite often this object would be a segment which could 
be created 
by the init$io 
procedure 
and filled with 


information 
needed by the other 
procedures 
in the 


driver. The token for this segment will be provided to 
the other procedures when they are called. 


NAME 
(14) 


FILE 
DRIVERS 


FUNCTIONS 


DEVICE 
GRANULARITY 


DEVICE 
SIZE 


FINISHSIO 
• 


DEVICE 
INFORMATION 
POINTER 


UNIT 
INFORMATION 
POINTER 


The final argument 
in the call is a pointer to a status 


word. This word should be assigned 
by the init$io 


procedure before a RETURN is executed. If a noh-zero 
value is returned indicating an error condition, the 110 
System assumes that init$io has deleted any objects 
created before the error was encountered. 


The finish$io procedure is called by the 110System just 
after the last detach$device 
call is made on the device. 


This 
procedure 
is expected 
to 
delete 
any 
objects 


created by the init$io procedure 
and shut down the 


connected device. 


Once again, the first parameter 
to the call is a pointer 
to a DUm. The second parameter 
is the token returned 
by the init$io procedure. 


The queue$io 
procedure 
is called to initiate 
an I/O 
request. 


The specifics of the request 
are indicated 
in an I/O 
request segment (IORS) which is provided by the first 
parameter. 
The format 
of this segment 
is shown in 
Figure 
18. The most important 
fields here are the 


count, function, status and buffer pointer fields which 
tell the queue$io procedure what needs to be done. The 
second 
and 
third 
parameters 
are 
once 
again 
the 
pointer 
to the DUIB and the token 
for the object 


The final device driver procedure 
is cancel$io. This 


procedure 
is called by the 110 System 
to cancel a 


previous I/O request. If the device is of such a nature 
that a request will complete in a bounded amount of 
time, this 
procedure 
can be a null procedure. 
The 


parameters 
to the call are identical 
to those for the 


queue$io call. 


In addition to the elementary 
support discussed here, 


the I/O System provides extra support to the designer 
of a device driver 
if some simplifying 
assumptions 


about 
the device can be made. Also, if the device 


supports 
random 
access 
(such 
as disks, 
magnetic 


bubbles, etc.), support routines can be used to simplify 
the process of blocking and deblocking I/O requests. 
More detail on the process of writing 110drivers can be 
found in the manual titled "A Guide to Writing Device 
Drivf'~s for the iRMX 86 110System." 


Design of an iSBC 534™ Device Driver 


The following section will discuss an example device 
driver for the iRMX 86 Operating System. The driver 
will be for the iSBC 534 board which contains 
four 


8251 USART devices; therefore, 
there is one device 


and four units on the device. 


The init$io 
procedure 
for this driver 
initializes 
the 


hardware, 
creates 
an interrupt 
task, 
creates 
other 


necessary objects and creates a segment to contain the 
relevant information. 


The structure 
of the 
queue$io 
procedure 
is more 


complex. When calls are made to this procedure to per- 
form data reading 
and writing, 
the actual operation 


could 
be 
somewhat 
lengthy 
(especially 
an 
input 


operation). Since the queue$io procedure is called by 
the I/O system, it is not efficient to perform the entire 
operation before control is returned to the I/O system. 


A more efficient mechanism is to have an independent 
task take the request and fulfill it while the queue$io 
procedure 
returns 
to the I/O system allowing other 


operations 
to be started 
in paralleL This leads to the 


structure 
diagrammed 
in Figure 19. When a read or a 


write request 
is received, the 1/0 request 
segment is 


sent to the request mailbox where it is received by an 
I/O handler 
task. When the request 
is complete, the 


I/O task sends the segment 
to the response mailbox 


indicated in the segment. 


Figure 19. Queue$io 
Procedure 
Interface 


to 1/0 Tasks 


The remaining design of the device driver is concerned 
with interrupt 
handling. The iSBC 534 board contains 


four 8251 USART devices. Each device supplies two 
interrupts; 
one indicating that the receiver has a data 


character 
available and the other indicating 
that the 


transmitter 
is ready to accept a character. 
Each of 


these interrupts 
(8 in all) are connected to one of the 


8259 Interrupt 
Controllers on the board. The software 


on the iSBC 86/12A board must read a register in the 
8259 controller to determine which of the eight sources 
caused the current 
interrupt. 
This information 
must 


then be fed to the I/O task which may be waiting for 
the event. 


One way to meet this requirement 
uses an interrupt 


task for the iSBC 534 board. The task receives the 
interrupt, 
determines 
which 
device caused 
it, and 


sends a unit to a semaphore to indicate the occurrence 
of the event. Thus, when an 1/0 task wishes to be 
informed 
of a receiver 
or transmitter 
interrupt, 
it 


simply tries to receive a unit from the appropriate 
semaphore. 
If a unit is available, 
the receiver has a 


character or the transmitter 
is ready. If the unit is not 


available, the USART is not ready and the task will be 
put in the asleep state until the interrupt 
occurs and 


the unit is sent. 


This chaper will present and analyze some sample code 
for the iRMX 86 applications 
presented in Chapter 4. 


The code listings are contained in Appendix A and the 
individual modules are numbered 
sequentially. 
When 


a specific line or sequence of lines of code must be 
pointed 
out in the text, a two part number 
is used 


where the first part is the module number 
and the 


second 
is the 
compiler-assigned 
line 
number. 
For 


example, 3.27 would be used to point out line 27 in 
module 3. 


A standard 
set of suffixes to labels will be followed in 


the code to follow. A PLlM-86 WORD variable that 
will contain the token for an iRMX 86 object will have 
the suffix "$t." A POINTER variable will be followed 
by "$p" and a structure 
used to overlay a POINTER 
allowing access to the base and offset will be followed 
by "$p$o." 


The first module to be studied contains 
the code for 


the listener task. The various include statements 
bring 


in literal 
declarations 
and external 
procedure 
decla- 


rations. 
The file NUCPRM.EXT 
is on the iRMX 86 


diskette and contains the external declarations 
for all 


iRMX 86 nucleus system calls. 


Line 1.323 contains 
all of the declarations 
for the 


module. 
The literal 
req$segment$struc 
is used 
to 


access the fields of a segment returned 
from the com- 


munications job. The format of a request packet from 
a workstation is shown in Figure 20. The literal node is 
used to access the information 
in a segment used as a 


workstation 
descriptor 
in a list maintained 
by the 


listener task. The format of a node in this list is shown 
in Figure 21. The structure 
at the end of the declara- 


tion statement 
is used to individually 
access the two 


halves of a 32-bit PL/M-86 
POINTER. 


Note in line 1.330 that the task is coded as a public 
procedure 
having no parameters. 
A main procedure 


should never be used for a task's code since the pre- 
amble for a main procedure sets the stack pointer. 


The mailbox to be used for sending a newly created 
worker 
task 
an information 
segment 
is called 
the 


log$on$info$mbox. 
This mailbox 
is created 
in line 


1.331. Lines 
1.332-1.334 
perform 
the operation 
of 


finding the tokens for the communication 
job's input 


and output request mailboxes in the object directory of 
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the root job. The token for the root job is obtained by 
the system call in 1.332. 


Whenever a workstation logs on, various actions are 
taken 
by the listener 
task. 
One of these 
actions 


involves adding a descriptor for the workstation to a 
list so that the state of the workstation can be main- 
tained by the listener task. The list structure is shown 
in Figure 22. Statements 
1.336-1.340 create the root 


of this list and initialize the list to an empty state. 


Line 1.340 marks the beginning of an infinite loop. 
Most often a task executes a procedure which performs 
some initialization 
and then enters an endless loop 


performing the necessary processing. The literal "for- 
ever" translates into "while 1:' 


A packet is received from the input mailbox by the call 
in line 1.341. The command field of the message is 
checked in line 1.343. If the command indicates that a 
log on request is being made, lines 1.345-1.356 are 
executed. A log on information segment is created in 
line 1.345. A mailbox is created to handle further 
request packets and another is created to be used by 
the worker task as a response mailbox. The worker 


task that will handle I/O requests from this work- 
station is created in line 1.351. Note the use of the 
structure data$seg$p$o, which is declared at the same 
address as the POINTER data$seg$p. The POINTER is 
initialized to equal the beginning of the data segment 
of the worker task module (1.323) and then the base 
portion is used as a parameter in the create task call. 


Once the worker task is created, it will wait at the 
log$on$info$mbox 
for a segment giving it its initiali- 


zation information. The segment is sent in line 1.352 
and received back as an acknowledgement in line 1.353. 
At this point, the segment is inserted on the list of 
active workstation descriptors by the call in line 1.354. 
Finally the request packet itself is sent to the worker 
task via the service mailbox for the new worker. 


If a log off request is received, lines 1.358 to 1.366 are 
executed. First, the active workstation list is searched 
for the ID of the requesting station. If the station is 
not found to be logged on, the status field is set and 
the request segment is sent to the workstation through 
the communications job. If the station is logged on, the 
descriptor is deleted from the list, the packet is sent 
along to the worker task, and the descriptor is deleted. 


If the command is anything but log on or log off, lines 
1.368-1.376 are executed. Once again the station ID is 
checked to see if it is logged on. If not, an error 
message is returned. If the station is logged on, the 
request packet is sent along to the worker task. 


WORKER 
TASK 


The code for the worker task is shown in module 2. 
Upon creation 
of a new worker 
task, a segment 
is 


received at the log$on$info$mbox 
(2.242). The data in 


this segment 
is copied into local variables 
and the 


segment is returned (2.247). 


The initialization 
task for this job has already created 


a user object for this job and has also set up a prefix 
which points to the root directory for the disk device. 
These tokens have been cataloged in the root object 
directory. 
The 
worker 
task 
obtains 
these 
tokens 


through the sequence of calls 2.248-2.250. 


The worker task now enters an infinite loop servicing 
the workstation 
it is assigned to. The specific action to 


be taken by the worker is determined by inspecting the 
cmd field of the request message. 


If the command is a log on, the code from 2.256-2.263 
is executed. 
The file name specified in the request 


segment 
is attached 
and opened and thereby 
made 


ready for subsequent 
I/O requests. 
After this, an ac- 


knowledgement 
is sent back to the workstation 
via the 


output$request$mailbox 
(2.263). 


If a log off command is received, the file is closed and 
detached, 
the 
service 
and 
response 
mailboxes 
are 


deleted, a response is sent to the workstation 
and the 


worker task is deleted. 


If the command is either a read or write command, the 
operation 
is performed 
by calling 
the I/O system. 
When the response is received, an acknowledgement 
is 


sent to the workstation. 
Note that 
the task would 


normally perform more processing. In this example its 
duties have been kept simple. 


POINTERIZE 
PROCEDURE 


The ASM-86 code for the pointerize support routine is 
shown in Module 3. The token for a segment is the 
base portion of a 32-bit POINTER to the memory. In 
order to access the data in a segment, this 16-bit token 
must be loaded into the base part of a POINTER while 
the offset portion of the POINTER is set to zero. The 
base and offset values are returned 
in the ES and BX 


regusters 
as specified 
by the PLlM-86 calling 
con- 


ventions. 
This 
is the 
operation 
performed 
by the 


pointerize routine. 
. 


LIST MANIPULATION 
ROUTINES 


Lines 4.1-4.47 provide three subroutines 
used by the 


tasks in this system to manipulate 
the list of work- 


station 
descriptors. 
Insert$on$list 
(4.15-4.26) inserts 


the indicated node at the head of the list whose root is 
given as the first parameter. 


Delete$from$list 
(4.27-4.35) 
unlinks 
the 
indicated 
node from the list it belongs to. Search$list (4.36-4.46) 
searches a list for the workstation 
ID given. If the ID is 


not found, a zero is returned. 
If the ID is found, the 


token for that node is returned. 


At this point an overview of the configuration 
process 


is needed. A more detailed coverage of the process of 
configuring 
an iRMX 86 system 
is provided 
in the 


manual 
entitled 
"iRMX 86 Configuration 
Guide for 


ISIS·II Users." 


For each iRMX 86 application, 
the following steps 


must be performed. 


1) Program code for each task in the system must be 


written and compiled or assembled. 


2) A memory map for the software must be drawn up. 
3) The system software must be linked and located. 
4) The application jobs must be linked and located. 
5) Tables of configuration 
data must be drawn up. 


6) The tabular 
data from step 5 must be formatted 


into a memory data block through 
the use of a set 


of ASM-86 macros 
provided 
with 
the iRMX 86 


product. 


7) The root job must be linked and located. 


The code executed by the root task is part of the iRMX 
86 system code. This task is initially the only task in 
the system. The root task will access the data block 
constructed by the ASM-86 macros and will create the 
user jobs specified by the macros. The data for the 
configuration 
process 
for 
example 
1 is shown 
in 


AppendixB. 


The first 
page diagrams 
the memory 
map for the 


example. The iterative 
link and locate process to put 


these pieces together 
begins on the second page. The 


LINK86 
and 
LOC86 
commands 
shown 
place 
the 


iRMX/86 
nucleus 
into memory. 
The LOCATE map 
indicates 
that the last memory location used by the 


nucleus was 077DFH. Therefore, 
the next contiguous 


piece, the 1/0 system, is located at 077EOH. 


This process is repeated for the remainder 
of the jobs 


in the system. 


When the link and locate process is complete, 
the 


information 
for the ASM-86 macros must be brought 


together. 
Worksheets 
are provided 
in the iRMX 86 


configuration guide to simplify this process. 


The filled-out worksheets for the macros are shown in 
the appendix. A configuration 
file is constructed 
using 


the editor and the worksheet information is entered 
into this file. When the file is complete, the con- 
figuration 
table is created 
by assembling 
the file 
CTABLE. A86. This file accesses the configuration file 
built earlier. 


The configuration tables are then linked and located 
together with the code for the root task and the system 
generation process is complete. 


INIT$IO AND FINISH$IO 


The start$and$finish 
module (5.1-5.371) contains the 


code for 
the 
init$534$io 
and 
finish$534$io 
pro- 


cedures. The init$534$io 
procedure 
creates 
a seg- 


ment, shown in Figure 23, which is used to hold the 
various pieces of information 
needed by the other 


driver 
procedures 
(5.323). The discussion 
of this 
procedure in Chapter 4 pointed out that any errors 
encountered in the initialization are indicated by the 
non-zero status and that the assumption is made that 
any partial creations must be cleaned up by the init$io 
procedure. This assumption is carried out by the check 
at line 5.324 (and the others at 5.331,5,335,5.339 
and 


5.342). 
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The device information contained in the device unit 
information block for this device is retrieved in line 
5.328-5.329. A mailbox to be used for sending IJO 
request segments to the IJOhandler tasks is created in 
line 5.330. The interrupt task for this job is created by 
the call in line 5.337. 


The do loop starting at line 5.340 is executed to create 
eight semaphores to be used by the interrupt 
task to 


indicate the occurrence of an interrupt. Note that the 
initial value of the semaphore is zero (no interrupt 


pending) and the maximum value is one. Since the 
nature of the 8251 USART device does not support 
buffering, when a new character overruns the previous 
character before the interrupt 
can be serviced, the 


data is lost. Therefore, there is no need to indicate the 
occurrence of multiple interrupts pending on the same 
device. 


The call at line 5.345 initializes the programmable 
devices on the iSBC 534 board. If execution has 
proceeded to line 5.346, the initialization is complete 
and a zero status is returned. If an error occurred at 
any point, the code in lines 5.348-5.356 will clean up 
the partial initialization. 


Thefinish$534$io 
procedure (5.358-5.370) undoes the 


work of the init$534$io 
procedure. 
The segment, 


mailbox, 
interrupt 
task 
and 
semaphores 
are 
all 


deleted. 


The queue$534$io 
procedure is shown in lines 6.1- 
6.382. In line 6.322 the function 
field of the IJO 


request 
segment 
is checked to see if it is within 


bounds. If jt is not, a bad status code is returned. If the 
function is valid, a do case block is executed using the 
function code as the index. 


If a read request is encountered, the auxiliary pointer 
is set to point to the ret$data 
structure 
(initialized 
earlier by the init$534$io procedure). In line 6.327 the 
segment is then sent to the request mailbox to be 
received and processed by an IJO processor task. In 
lines 6.330-6.334 the same action is taken with write 
requ!!sts. 


Since this driver does not support seeking and special 
functions, the code for these two cases simply returns 
an error condition. 


In the case of an attach$device 
call, the code in lines 


6.3,41-6.361 is executed. First, 
two IJO processing 


tasks are created. All of these tasks execute identical 
code and each task is capable of servicing a read or a 
write request on any 8251. Two tasks are created for 
each 8251 device so that the peak load can always be 
handled (that is, all receivers and transmitters 
going 
simultaneously). Lines 6.346-6.357 perform the initi- 
alization of the 8251 USART and the baud rate gen- 
erators for this channel. The calls in line 6.358 and 
6.359 accept an interrupt 
and a character from the 
semaphore associated with the receiver just initialized. 
This is done to clear off an interrupt generated by the 
8251 whenever it is initialized. 


In the case of a detach$device 
call, the code in lines 
6.363-6.367 sends the IJO request 
segment 
to the 


request mailbox twice. This is done to signal two of the 
110 handler tasks to delete themselves. As discussed 
earlier in the attach$device 
section, none of the 110 
handler tasks is any different from any of the others. 
There are two created for each 8251 device which is 
attached. 
The protocol set up for their deletion is 


shown here. When an 110 handler 
task receives a 


segment 
of type 
"detach$device" 
it will send the 


segment to the response mailbox and then delete itself. 


The code for the open and close requests is the same. 
Both cases are supported 
but are NOPs since no 


specific action needs to be taken by the driver. 


Lines 6.379-6.382 contain the code for the cancelS 
534$io procedure. 
As discussed 
earlier, 
this 
pro- 


cedure is simply a placeholder and serves no par- 
ticular purpose. 


INTERRUPT 
CONTROL 
MODULE 


The interrupt handler and interrupt task are shown in 
lines 7.1-7.329. The interrupt 
task is the first piece 


executed. It is created by the init$534$io procedure. It 
calls RQ$set$interrupt 
in line 7.325 to indicate to the 


iRMX86 nucleus that it is an interrupt task. 


Once the initialization is complete, the task enters an 
infinite loop. The call to RQ$wait$interrupt 
in line 


7.322 causes the task to be put into the asleep state 
until an interrupt occurrence is signaled. The task will 
be returned to the READY state when an interrupt 
occurs, the interrupt handler is started, and the call to 
RQ$signal$interrupt 
is executed at line 7.312. The 


current interrupt 
level is then determined by polling 


the 8259 chip on the iSBC 534 board. Using the 
encoded level number, a unit is sent to the appropriate 
semaphore to indicate that an interrupt is pending. 


1/0 TASK 


The final procedure that makes up this driver contains 
the code for the tasks that perform the actual 110 to 
the iSBC 534 board. The loop executed by each task 
starts by waiting at the request mailbox for an 1/0 
request segment. When the segment is sent by the 
queue$534$IO 
procedure, its function code is checked 


(line 8.327, 
8.332, 
8.340). If the 
function 
is i$ 


detach$device, 
the task sends the segment 
to the 


response mailbox and then deletes itself. 


If the request was for a read, the task fills the buffer 
with input data. The call at line 8.334 waits for a unit 
at the semaphore which will indicate a receiver ready 
on the input line. When the unit is sent by the in- 
terrupt task, the character is read in, the pointers and 
counts are updated, and another unit is requested. 


The last request which is recognized by the 110 task is 
for a write operation. The code for this request is 
almost identical to the code for a read request. An 
interrupt from the transmitter 
is awaited, a character 


is output and the counts are updated in lines 8.341- 
8.346. 


Once the request is fulfilled, the message is sent to the 
response exchange in line 8.350. 


The configuration of this system is studied next. The 
code for the iSBC 534 driver is linked directly to the 
rest of the 
110 system 
libraries. 
The entry 
point 


addresses for the queue$534$io, 
cancel$534$io, 
init$ 


534$io, and iinish$534$io 
procedures are declared in 


the IOCNFG.A86 file on the 110 system disk. This file 
also contains the device unit information block (DUIB) 
structures for the four units on the iSBC 534 board. 
The unique information for the iSBC 534 device and 
the units on the device is contained in the device and 
unit information tables. Pointers to these tables are 
contained 
in 
the 
DUIB 
structures. 
All 
of 
this 


information is shown in Figure 24. 


The submit file used to build an 110 system using the 
iSBC 534 driver 
is shown in Figure 25. The file 


DRV534.LIB contains the object files generated by 
PL/M-86 
and ASM-86 from the source code shown in 


modules 5-9. 


This application note is an introduction to the iRMX 
86 Operating System. The requirements of operating 
systems were studied along with traditional solutions. 
Following this, the iRMX 86 Operating System was 
introduced and its correlation with the requirements 
was studied. 


Later in the application 
note, the topic of system 


design was covered. Example solutions were studied to 
solidify 
a methodology 
for 
solving 
application 


problems and then the code for these solutions was 
discussed to gain insight into the details of imple· 
menting iRMX86 systems. 


The 
purpose 
of a 
configurable, 
real-time, 
multi· 
purpose operating system is to provide a solid foun- 
dation for application software. The iRMX 86 system 
provides this foundation, giving the software engineer 
a means to quickly and easily implement new designs. 
In addition, the iRMX 86 architecture is the bridge to 
future technology providing the designer with an up- 
grade path to future hardware and software products. 


extrn 
ex trn 
ex trn 
ex trn 


init534io: 
near 
queue534io: 
near 
cance1534io: 
near 
finish534io: 
near 


define 
duib 


& 
- 


"3H, 
~~~33H, 
~, 
l!I, ~, 


supp$opt 
file 
drivers 
granularity 
device 
size 


& 


& 


& 


& 


& 
& 


& 


& 


& 
&) 


; 
534 


3, 
1, 
6, 
init534io, 
finish534io, 
queue534io, 
cance1534io, 
dev 
534 
info, 
unit_534_l_info 


device 
unit 
device 
uni t 
init$io 
finishSio 
queueSio 
cancel$io 
device 
info 
unit_info 


48H 
61 
~4 ~H 


level 
priority 
base 
address 


unit 
info: 
iSBC 
534.1 


~nit 
534 
1 
info 
db 


- 
dw 


unit 
info: 
iSBC 
534.2 


~nit 
534 
2 
info 
db 
dw 


asm86 
:f1:iocnfg.a86 
date{%~) 
print{:f5:iocnfg.1st) 
1ink86 
& 


:fl:ios.lib(ioinit), 
& 


:fl:iocnfg.obj, 
& 
:fl:ios.lib, 
& 


:f 1:drv534.1 
ib, 
& 


:f4:rpifc.lib 
& 
to 
:fl:ios.lnk 
map 
print(:fl:ios.mpl) 
10c86 
:fl:ios.lnk 
to 
:fl:ios 
map 
sc(3) 
print(:fl:ios.mp2) 
& 


oc(noli,nopl,nocm,nosb) 
& 


order(classes(code,data,stack,memory)) 
& 
addresses(classes{code{%l))) 
& 


segsize(stack(l!I)) 


APPENDIX 
A 
2-97 
APPEN DIX B 
2-121 


APPENDIXA 
Code Listings 


ISIS-II 
PL/M-86 
V2.0 
COMPILATION 
OF 
MODULE 
LISTENERMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:listen.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:listen.plm 
PRINT(:Fl:LISTEN.LST) 
DEBUG 
COMPACT 
OPTIMIZE(3) 
ROM 
DATE(5/28/8e 


321 
322 


listener$module: 
do; 


This 
task 
creates 
segments, 
sends 
them 
to 
the 
input 
service 
job 
to 
be 
filled 
with 
input 
packet 
info. 
Upon 
response 
the 
info 
is 
checked 
to 
see 
what 
action 
needs 
to 
be 
taken. 
If 
a 
log$on 
request 
is 
sensed, 
a worker 
task, 
service 
mailbox, 
and 
response 
mailbox 
are 
created 
and 
the 
packet 
is 
sent 
along 
to 
the 
worker 
task. 
If a 
log$off 
is 
sensed 
all 
local 
reference 
to 
the 
workstation 
is 
deleted 
and 
the 
packet 
is 
sent 
along 
to 
tell 
the 
worker 
to 
delete 
himself. 
If an 
1/0 
request 
is 
sensed 
the 
station 
ID 
is 
checked 
to 
make 
sure 
it 
is 
logged 
on. 
If 
it 
is, 
the 
packet 
is 
sent 
along 
to 
the 
worker. 
If 
it 
isn't 
an 
error 
packet 
is 
sent 
back 
to 
the 
requesting 
workstation. 


$include( 
:f2:common.lit) 
$SAVE 
NOLIST 
$include(:fl:node.lit) 
1* 
literal 
declaration 
o~ 
node 
descriptor 
for 
list 
utilities 
*1 


declare 
node 
literally 
'structure( 
link$f 
word, 
link$b 
word, 
work$station$ID 
word, 
service$mbox$t 
word, 
worker$task$t 
word, 
resp$mbox$t 
word) '; 
$ incl ud e (:f 1:1 stutl .ex t) 
1* external 
declarations 
for 
list 
manipulation 
utilities 
*1 


$save 
nolist 
$include(:fl:pointr.ext) 
1* external 
declaration 
of 
pointerize 
procedure 
*1 
$save 
nolist 
$include(: 
fl: rqpckt.l 
it) 
1* 
literal 
declaration 
for 
request 
packet 
structure 
*1 


declare 
req$segment$struc 
literally 
'structure( 
funct 
word, 
count 
word, 
actual 
word, 
ex$ val 
wo rd, 
work$station$ID 
word, 
cmd 
word, 
share 
word, 
mode 
word, 
status 
word, 
file$name 
(64) 
byte, 
buf 
(128) 
byte)'; 
$include( 
:f2:nucprm.ext) 
$SAVE 
NOLIST 


worker$task: 
procedure 
external; 
end 
worker$task; 


324 
1 


325 
2 
326 
2 
327 
2 
328 
2 
329 
2 


330 
1 


331 
2 
332 
2 
333 
2 


335 
336 
337 
338 


339 


342 
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344 


declare 
begin$listener$task$data 
byte 
public, 
begin$worker$taskSdata 
byte 
external, 
log$on$info$mbox$t 
token 
public, 


ex$val 
word, 
logS on$mbox$ 
name 
(7) 
byte 
data (6, ,LOG$ON' ) , 


packet$size 
literally 
'132', 
f$read 
literally'S', 
f$write 
literally 
'6', 
log$on 
literally 
'0', 
log$off 
literally 
'1', 
not$logged$on 
literally 
'1', 


(rootS job$ t, input$ reqIJest$mbox$ t) 
token, 


(output$ request$mbox$ 
t, resp$mbox$ 
t) 
token, 


(wo rk$stat ion$l ist$ roo t$ t, req$ segmentS 
t) 
token, 
(logS on$ in fo$ seg$ t,d ummy$t, ws$desc$ 
t) 
token, 
(req$ segmen t$ p, wo rk$stat ion$l ist$ roo tSp) 
po inter, 


(log$on$infoSseg$p,data$seg$p,ws$desc$p) 
pointer, 


(req$segment 
based 
req$segment$p) 
req$segment$struc, 


(work$station$list$root 
based 
work$station$list$root$p) 
node, 


(log$on$info$seg 
based 
log$on$info$seg$p) 
node, 
data$seg$p$o 
structure 
(offset 
word, 
base 
word) 
at (@data$seg$p) 
, 


(ws$desc 
based 
ws$desc$p) 
node; 


req$segment.funct=f$write; 
req$segment.status=not$logged$on; 
call 
rq$send$message(output$request$mbox$t,req$segment$t,0,@ex$val); 


return; 


end; 


10gSon$info$mbox$t=rq$create$mailbox(0,@ex$val); 
root$job$t=rq$get$task$tokens(3,@ex$val); 
input$request$mbox$t=rq$lookup$object( 


/* job 
*/ 
root$job$t, 


/* 
name */ 
@(9,'INPUT$REQ'), 


/* time 
limit 
*/ 
0FFFFH, 


/* status 
ptr 
*/ 
@ex$val); 


output$request$mbox$t=rq$lookup$object( 


/* job 
*/ 
root$job$t, 


1* 
name */ 
@(10,'OUTPUT$REQ'), 


/* time 
limit 
*/ 
0FFFFH, 


/* status 
ptr 
*/ 
@ex$val); 


resp$mbox$t=rq$create$mailbox(0,@ex$val); 
work$station$list$root$t=rq$create$segment(16,@ex$val); 
work$station$list$root$p=pointerize(work$station$list$root$t); 
work$station$list$root.link$f, 
work$station$list$root.link$b=work$station$list$root$t; 
work$station$listSroot.workstation$ID=0; 


req$segment$t 
= 
rq$receive$message( 


/* mbox 
token 
*/ 
input$request$mbox$t, 


/* time 
limit 
*/ 
0FFFFH, 


/* 
response 
ptr 
*/ 
@dummy$t, 


/* status 
ptr 
*/ 
@ex$val); 
req$segment$p=pointerize(req$segment$t); 


if 
req$segment.cmd= 
logS on 
then 
do; 


357 
358 
359 


else 
if 
req$segment.cmd 
= 
log$off 
then 
do; 


362 
363 
364 


else 
do; 


log$on$info$seg$t=rq$create$segment( 
/ * 
size 
*/ 
I 6, 
/* 
status 
ptr*/ 
@ex$val); 
log$on$info$seg$p=pointerize( 
log$on$info$seg$t); 
log$on$info$seg.service$mbox$t= 
rq$create$mailbox(0,@ex$val); 
log$on$info$seg.resp$mbox$t= 
rq$create$mailbox(0,@ex$val); 
log$on$info$seg.work$station$ID= 
req$segment.work$station$ID; 
data$seg$p=@begin$worker$task$data; 
log$on$info$seg.worker$task$t= 
rq$create$ 
task ( 


/* 
priority 
*/ 


/* 
start 
addr 
*/ 
/* 
data 
seg 
ptr 
*/ 


/* 
stack 
pointer 
*/ 


/* 
stack 
size 
*/ 
/* 
task 
flags 
*/ 


/* 
status 
ptr 
*/ 


200, 
@worker$task, 
data$seg$p$o.base, 
0, 
500, 
0, 
@ex$val) 
; 


call 
rq$send$message( 


/* 
mbox 
token 
*/ 
log$on$info$mbox$t, 


/* 
object 
token 
*/ 
log$on$info$seg$t, 


/* 
response 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 


logSon$info$segSt=rq$receive$message( 
/* 
mailbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 
/* 
response 
token 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 


call 
insert$on$list(work$station$list$root$t, 


log$on$info$seg$t); 
call 
rq$send$message( 


/* 
mbox 
tok 
*/ 
log$on$info$seg.service$mbox$t, 
/* 
obj 
tok 
*/ 
req$segment$t, 


/* 
response 
*/ 
0, 


/* 
status 
*/ 
@ex$val); 


ws$desc$t=search$list(work$station$list$root$t, 


req$segment.work$station$ID); 
if ws$desc$t 
= 
0 then 
call 
retllrn$error$to$WS; 
else 
do; 
ws$descp=pointerize(ws$desc$t); 
call 
delete$fromSlist( 
ws$desc$t) 
; 
call 
rq$send$message( 
ws$desc.service$mbox$t, 
req$segment$t, 
0, 
@ex$val); 


ws$desc$t=search$list(work$station$list$root$t, 


req$segment.work$station$ID); 
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if 
ws$desc$t=0 
then 
call 
return$error$to$WS; 
else 
do; 
ws$descp~pointerize(ws$desc$t); 
call 
rq$send$message( 
ws$desc.service$mbox$t, 
req$ segmentS t, 
0, 
@ex$val) 
; 
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378 


end; 
call 
rq$del~te$segment(req9segment$t,@ex$val); 
end; 
/* of 
do 
forever 
*/ 


CODE 
AREA 
SIZE 


CONSTANT 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 


694 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


0281H 
0000H 
002BH 
0018H 


641D 


0D 
43D 
24D 


ISIS-II 
PL/M-86 
V2.0 
COMPILATION 
OF 
MODULE 
WORKERTASK 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:worker.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:worker.plm 
PRINT(:Fl:WORKER.LST) 
DEBUG 
COMPACT 
OPTIMIZE(3) 
ROM 
DATE"(5/28/80l 


worker$task: 
do; 


This 
module 
contains 
the 
code 
executed 
by 
the 
worker 
tasks. 


When 
started, 
the 
task 
goes 
to 
a mailbox 
to 
receive 
a 
segment 
containing 
initialization 
information. 
Using 
this 
information 


the 
task 
services 
a 
service 
mailbox 
performing 
any 
I/O 
functions 


requested 
of 
it. 
When 
a 
log$off 
request 
comes 
in 
the 
worker 


task 
closes 
and 
detaches 
the 
file 
and 
deletes 
itself. 


$include( 
:fl:nucprm.ext) 
$SAVE 
NOLIST 
$ inc1ud e (:f 1:i0 sys •ext) 
$save 
nolist 
$include(: 
f l:node.l 
it) 


/* literal 
declaration 
of 
node 
descriptor 
for 
list 
utilities 
*/ 


$save 
nolist 
$include(:f2:common.lit) 
$SAVE 
NOLIST 
$include(:fl:pointr.ext) 
/* external 
declaration 
of 
pointerize 
procedure 
*/ 


$save 
nolist 
$include(:fl:rqpckt.lit) 
/* 
literal 
declaration 
for 
request 
packet 
structure 
*/ 


declare 
read 
literally 
'I', 
write 
literally'S', 
log$on 
literally 
'2', 


log$off 
literally 
'3', 
(log$on$ info$mbox$ 
t,o utput$ request$mbox$ 
t) 
token 
external; 


declare 
(log$on$info$seg$t,log$on$resp$mbox$t,resp$mbox$t, 
root$job$t,user$object$t,prefix$t,iors$t, 
serv ice$mbox$ 
t ,conn$ t, req$ seg$ t) 
token, 
(log$on$info$p,req$seg$p) 
pointer, 
(req$ seg 
based 
req$ seg$ p) 
req$ segmentS str uc, 
(log$on$info 
based 
log$on$info$p) 
node, 
(dummy$t,ex$val,work$station$ID) 
word; 


log$on$info$seg$t=rq$receive$message( 
/* mbox 
token 
*/ 
log$on$info$mbox$t, 


/* time 
limit 
*/ 
0FFFFH, 


/* response 
ptr 
*/ 
@log$on$resp$mbox$t, 


/* status 
ptr 
*/ 
@ex$val); 


log$on$info$p=pointerize(log$on$info$seg$t); 
service$mbox$t=log$on$info.service$mbox$t; 
resp$mbox$t=log$on$info.resp$mbox$t; 
work$station$ID=log$on$info.work$station$ID; 
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call 
rq$send$message( 
/* 
mbox 
token 
*/ 
log$on$resp$mbox$t, 


/* 
object 
token 
*/ 
log$on$info$seg$t, 


/* 
response 
token 
*/ 
0, 


/* 
status 
ptr 
*/ 
@ex$val); 


248 
249 
root$job$t=rq$get$task$tokens(3,@ex$val); 
user$object$t=rq$lookup$object( 
/* 
job 
token 
*/ 
root$job$t, 


/* 
name 
*/ 
@(ll,'USER$OBJECT'), 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
status 
ptr 
*/ 
@ex$val); 


prefix$t=rq$lookup$object( 
/* 
job 
token 
*/ 
root$job$t, 


/*name*/ 
@(6,'PREFIX'), 


/* 
time 
limit. */ 
0FFFFH, 


/* 
status 
ptr 
*/ 
@ex$val); 


req$seg$t=rq$receive$message( 
/* 
mailbox 
token 
*/ 
service$mbox$t, 


/* time 
limit 
*/ 
0FFFFH, 


/* response 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 


if 
req$seg.cmd=log$on 
then 
do; 
254 
255 
256 
call 
rq$a$attach$file( 


/* 
user 
object 
*/ 
user$object$t, 


/* 
prefix 
token 
*/ 
prefix$t, 
/* 
pathname 
*/ 
@req$seg.file$name, 


/* 
resp 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rq$receive$message( 
/* mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$delete$segment(iors$t,@ex$val); 
call 
rq$a$open( 


/* 
connection 
*/ 
conn$t, 


/* 
mode 
*/ 
req$seg.mode, 


/* 
share 
*/ 
req$seg.share, 


/* 
resp 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rq$receive$message( 
/* 
mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* resp 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$delete$segment(io~s$t,@ex$val); 
req$seg.status=0; 
call 
rq$send$message( 


/* 
mbox 
token 
*/ 
output$request$mbox$t, 


/* 
object 
token 
*/ 
req$seg$t, 


/* 
resp 
ptr 
*/ 
0, 


/* 
status 
ptr 
*/ 
@ex$val); 
end; 
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262 
263 
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else 
if 
req$seg.cmd=log$off 
then 
do; 
call 
rq$a$close 
( 


/* 
connection 
*/ 
/* 
resp 
token 
*/ 
/* 
status 
ptr 
*/ 


conn$t, 
resp$mbox$t, 
@ex$val); 


iors$t= 
rq$receive$message( 


/* 
mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@aummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 


call 
rq$delete$segment(iors$t,@ex$val); 
call 
rq$a$delete$connection( 
/* 
connection 
*/ 
conn$t, 


/* 
response 
ptr 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rq$receive$message( 
/* 
mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
~FFFFH, 


/* 
response 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$delete$segment(iors$t,@ex$val); 
call 
rq$delete$mailbox(service$mbox$t,@ex$val); 
call 
rq$delete$mailbox(resp$mbox$t,@ex$val); 


req$seg.status=0; 
call 
rq$send$message( 
/* 
mbox 
token 
*/ 
output$request$mbox$t, 


/* 
object 
token 
*/ 
req$seg$t, 


/* 
resp 
token 
*/ 
0, 


/* 
status 
ptr 
*/ 
@ex$val); 


call 
rq$delete$task(0,@ex$val); 
end; 
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else 
if 
req$seg.cmd=read 
then 
do; 


call 
rq$a$read( 
/* 
connection 
*/ 
conn$t, 


/* 
buf 
ptr 
*/ 
@req$seg.buf, 


/-* count 
*/ 
req$seg.count, 


/* 
resp 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rq$receive$message( 
/* 
mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit-*/ 
0FFFFH, 
/* 
resp 
ptr 
*/ 
@dummy$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
call 
rq$delete$segment(iors$t,@ex$val); 
req$seg.status=0; 
call 
rq$send$message( 


/* 
mbox 
token 
*/ 
output$request$mbox$t, 


/* 
object 
token 
*/ 
req$seg$t, 


/* 
resp 
token 
*/ 
0, 


/* 
status 
ptr 
*/ 
@ex$val); 


end; 


283 
284 
285 


286 


287 
288 
else 
if 
req$seg.cmd=write 
then 
do; 


call 
rq$a$write( 


/* 
connection 
*/ 
conn$t, 


/* 
buf 
ptr 
*/ 
@req$seg.buf, 


/* 
count 
*/ 
req$seg.count, 


/* 
resp 
token 
*/ 
resp$mbox$t, 


/* 
status 
ptr 
*/ 
@ex$val); 
iors$t=rq$receive$message( 
/* 
mbox 
token 
*/ 
resp$mbox$t, 


/* 
time 
limit 
*/ 
0FFFFH, 


/* 
resp 
ptr 
*/ 
@dummy$t, 


1* 
status 
ptr 
*/ 
@ex$val); 


call 
rq$delete$segment(iors$t,@ex$val); 


call 
rq$send$message( 


/* mbox 
token 
*/ 
output$request$mbox5t, 
/* object 
token 
*/ 
req$seg$t, 


/* resp 
token 
*/ 
0, 


/* status 
ptr 
*/ 
@ex$val); 
end; 
end; 
/* of 
do 
forever 
*/ 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
717 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


0288H 
0000H 
0000H 
0~n4H 


648D 
0D 
0D 
52D 


ISIS-II 
MCS-86 
MACRO 
ASSEMBLER 
V2.0 ASSEMBLY 
OF MODULE 
POINTR 


OBJECT 
MODULE 
PLACED 
IN 
:F1:POINTR.OBJ 


ASSEMBLER 
INVOKED 
BY: asm86 
:f1:pointr.a86 
debug 
pr(:f5:pointr.1st) 


0000 
55 
0001 
RBEC 


0003 
8E4604 
0006 
33DB 


0008 
5D 
0009 C2f1200 


LINE 
SOURCE 


1 
"$tit1e(pointerize 
Uti1 ity) 


2 
arg 
off 
equ 
4 
; set 
arg s for 
"DELUXE" 
3 
4 
code 
segment 
word 
public 
'CODE' 


5 
code 
ends 
6 
7 
cg roup 
9 roup 
code 


8 
code 
segment 


9 
assume 
cs: 
cgroup 
10 
11 
po inter ize 
proc 
near 


12 
puh1ic 
pointedze 


13 
push 
bp 
save 


14 
mov 
bp, 
sp 
mark 
stack 


15 
16 
token 
equ 
word 
ptr 
[bp + 
arg off 
+ 
(I ] 
17 
18 
mov 
es, 
token 
get 
base 


19 
xo r 
bx, 
hx 
zap 
offset 
20 
21 
mov 
sp, hp 
restore 
stack 
22 
pop 
bp 
23 
ret 
2 
24 
pointed 
ze 
endp 
25 
code 
ends 


26 
end 


ISIS-II 
PL/M-86 
X167 
COMPILATION 
OF 
MODULE 
LISTUTILITIESMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:lstutl.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:lstutl.plm 
PRINT(:F5:LSTUTL.L~T) 
DEBUG 
COMPACT 
OPTIMIZE(3) 
ROM 
DATE(3/7/80) 


list$utilities$module: 
do; 


This 
module 
contains 
three 
list 
manipulation 
utilities. 


Insert$on$list 
takes 
the 
given 
node 
and 
inserts 
it 
on 
the 


list 
indicated 
by 
the 
root 
node 
parameter. 
Delete$from 
list 
unlinks 
the 
indicated 
node 
from 
the 
list 
it 
is 
linked 
to. 
SearchSlist 
scans 
the 
list 
from 
the 
root 
looking 
for 
the 
indicated 
node. 
If 
found, 
the 
token 
for 
the 
node 
is 
returned. 
If 
not 
found, 
a 
zero 
is 
returned. 


Sinclude(:f4:common.lit) 
$SAVE. NOLIST 
$include(:fl:node.lit) 
/* literal 
declaration 
of 
node 
descriptor 
for 
list 
utilities 
*/ 


$save 
nolist 
$include(: 
f l:pointr 
.ext) 


/* external 
declaration 
of 
pointerize 
procedure 
*/ 
$save 
nolist 


declare 
(root$ t ,new$desc$ 
t, fwd$desc$ 
t) 
token, 
(rootSp,newSdesc$p,fwd$desc$p) 
pointer, 
(root 
based 
rootS p) 
node, 
(newSdesc 
based 
newSdescSp) 
node, 
(fwdSdesc 
based 
fwdSdescSp) 
node; 


root$p=pointerize(rootSt); 
newSdescSp=pointerize(newSdesc$t); 
fWd$desc$t=root.linkSf; 
fwd$descSp=pointerize(fwdSdescSt); 
root.linkSf=newSdescSt; 
new$desc.linkSf=fwd$descSt; 
new$desc.linkSb=rootSt; 
fWdSdesc.linkSb=newSdesc$t; 
return; 


declare 
desc$t 
token, 
(descSp,bSdescSp,fSdescSp) 
pointer, 
(desc 
based 
descSp) 
node, 
(bSdesc 
based 
bSdescSp) 
node, 
(fSdesc 
based 
fSdescSp) 
node; 


desc$p=pointerize(descSt); 
bSdescSp=pointeri 
ze (desc.l inkSb); 
fSdescSp=pointerize(desc.linkSf); 
b$desc.linkSf=desc.linkSf; 
fSdesc.link$b=desc.linkSb; 
return; 


declare 
(root$t,WS$ID) 
word, 
(s$desc$p,root$p) 
pointer, 


(root 
based 
root$p) 
node, 


(s$desc 
based 
s$desc$p) 
node, 


s$desc$p$o 
structure 
(offset 
word, 
base 
word) 
at(@s$desc$p), 


temp 
pointer; 


s$desc$p=pointerize(root$t); 
next$node: 


if 
s$desc.work$station$ID=WS$ID 
then 
return 
s$desc$p$o.base; 
if 
s$desc.linkSf 
= 
root$t 
then 
return 
VI; 
temp=pointerize(sSdesc.link$f); 
s$desc$p=temp; 
goto 
next$node; 


CODE 
AREA 
SIZ E 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
114 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


l'lVlFEH 


"''''l'lClH 
0l'lfHiJH 
fH'Jl flH 


254D 


fJD 
0D 


24D 


ISIS-II 
PL/M-86 
X167 
COMPILATION 
OF 
MODULE 
STARTANDFINISH 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:strfin.OBJ 


COMPILER 
INVOKED 
BY: 
plm86 
:Fl:strfin.plm 
PRINT(:F5:STRFIN.LST) 


DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE (4/28/80) 


start$and$finish: 
do; 


This 
module 
contains 
the 
init$534$IO 
and 
the 
FINISHS534$IO 


procedures 
which 
can 
be 
called 
by 
the 
RMX/86 
1/0 
system. 
STARTSIO 


is 
called 
just 
before 
the 
flrst 
attachSdevice 
is 
performed. 


It 
will 
create 
the 
interrupt 
task 
and 
the 
eight 
interrupt$pending 


semaphores. 
The 
FINISH$IO 
procedure 
is called 
just 
after 
the 


last 
detach$device 
is 
performed. 
It 
undoes 
everything 
the 
START$IO 


call 
did. 


$incl ud e{: f 4:nucprm.ext) 
$SAVE 
NOLIST 
$include(:f4:common.lit) 
$SAVE 
NOLIST 
$include{: 
f l:duib.l 
it) 


1* duib 
structure 
definition 
*/ 
$save 
nolist 


$include{:f4:nerror.lit) 


$SAVE 
NOLIST 


$include{: 
f l:pointr 
.ext) 


1* 
external 
declaration 
of 
pointerize 
procedure 
*1 
$save 
nolist 


S incl ud e (:f 1:retd ta.l it) 
1* 
literal 
declaration 
of 
retSdata 
structure 
for 
init$534Sio 
*1 
$save 
nolist 


314 
315 
316 


init$534$hw: 
procedure{data$p) 
external; 


declare 
data$p 
pointer; 
end 
init$534$hw; 
1* 
initializes 
534 
hardware 
*1 


int$534$task: 
procedure 
external; 
end 
int$534$task; 


317 
318 


declare 


begin$int$534$data 
byte 
external, 
IO$base$addr 
byte 
public, 
int$level 
word 
public, 
g$ret$dataSp 
pointer 
public, 


req$mbox$t 
token 
public; 


init$534$IO: 
procedure(duib$p,ret$data$t$p,status$p) 
reentrant 
public; 


declare 


(dui bSp,retSdat"StSp,sti'ltusSp) 
point.er, 


(duib 
baseo 
duibSp) 
nev$uni 
tSinfoSblock, 


(retSdataSt 
baseo 
retSdati'lStSp) token, 


(status 
baseo 
statusSp) 
word, 


dev$infoSp 
pointer, 


devSinfo 
based 
devSinfoSp 
structure( 
level 
word, 


priority 
byte, 


IOSbase$addr 
byte), 


322 
2 


323 
'2 
324 
2 
325 
2 
326 
2 
327 
2 
328 
2 
329 
2 


33'" 
2 


331 
2 
332 
2 


333 
? 
334 
2 
335 
2 


336 
2 
337 
2 


340 
341 


342 
3 


343 
3 


344 
3 
345 
2 
346 
2 
347 
2 


348 
? 


349 
3 
35'" 
3 


351 
2 
352 
2 


353 
2 


354 
2 


data$seg$p 
pointer, 


data$seg$p$o 
structure 
(offset 
worn ,base 
word) 
at (Iildata$seg$p) , 
(i ,j) 
byte; 


declare 
ret$dataSp 
pointer, 
ret$data 
basen 
ret$data$p 
structure(ret$dataSstruc); 


retSdata$t=rg$create$segMent 
(si ze (ret$data) 
,(i1exSval); 
if 
exSval 
<> 
'" then 
goto 
err"'; 
gSret$dataSp,retSdataSp=pointerize(ret$dataSt); 
devSinfoSp=duib.nevSinfoSp; 
IO$base$addr,retSdata.IOSbase=devSi~fo.IOSbaseSaddr; 
int$level,ret$data.intSlevel=devSinfo.level; 


ret$data.reguest$mboxSt,reg$mboxSt 
=rg$createSmaiJbox(0,~exSval); 
if 
ex$val 
<> 
'" then 


goto 
errl; 


ret$data.respSmbox$t=rg$createSmailbox(0,(i1ex$val); 
if 
ex$val 
<> 
'" then 


goto 
err2; 
1* clean 
up 
partial 
creation 
*1 


data$seg$p=(i1begin$int$534Sdata; 
ret$data.intStaskSt=rgScreate$task( 
1* 
priority 
*1 
dev$info.priority, 


1* entry 
point 
*1 
(i1intS534$task, 


1* data 
segment 
*1 
dataSsegSpSo.base, 


1* 
stack 
pointer 
*1 0, 


1* stack 
size 
*1 
400, 


/* 
task 
flags 
*/ 
0, 


1* 
status 
pointer 
*/ 
(i1exSval); 


if 
ex$val 
<> 
r then 


goto 
err3; 
1* can't 
create. 
clean 
up 
partial 
creation 
*1 


do 
i=0 
to 
7; 1* create 
semaphores 
*1 


ret$data.int$sema(i)=rg$create$semaphore( 
1* 
initial 
value 
*1 Pl, 


1* Max 
value 
*1 
1, 


1* priority 
gueue 
*1 
1, 


1* 
status 
ptr 
*/ 
(i1exSval); 


end; 
call 
init$534Shw(retSdataSp); 


status=ESOK; 
return; 


err4: 
do 
j=0 
to 
i; 


call 
rgSdeJeteSsemaphore(retSnata.intSsema(j) 
,status$pl; 
end; 
call 
rg$resetSinterrupt(dev$info.level,statusSp); 
err3: 
call 
rgSceleteSmailbox(retSdata.respSmboxSt,statusSp); 
err2: 
call 
rgSdeleteSmailbox(retSdata.reguestSmboxSt,statusSp); 


errl: 
call 
rgSdeJeteSsegment(retSdataSt,status$p); 


356 
357 


3fi'l 
2 
361 
2 
3fi2 
2 
3fi3 
2 
3fi4 
2 
3fi5 
2 
366 
3 


3(;7 
3 


3fiS 
2 


3fi9 
2 
370 
2 


371 
1 


err'l: 
status=exSval; 
/* 
restore 
original 
status 
condition 
*/ 
return; 


end; 
/* 
of 
procedure 
*/ 


finishS534SIO: 
procedure(duibSp,retSdataSt) 
reentrant 
public; 
declare 
duibSp 
pointer, 


devSinfoSp 
pointer, 


devSinfo 
based 
devSinfoSp 
structure( 
level 
word, 


priority 
byte, 


IOSbaseSaddr 
byte), 
retSdataSp 
pointer, 


retSnata 
based 
retSdataSp 
structure( 
retSdataSstruc) 
, 
(duib 
based 
duibSp) 
devSuni 
tS infoSblock, 


retSdataSt 
token, 


i 
byte, 


exSval 
word; 


devS 
infoSp=duib.rlevS 
infoSp; 


retSdataSp=pointeri 
ze (retSdata$t); 


call 
rqSresetSinterrupt(devSinfo.level,~exSval); 


call 
rqSdeleteSmailbox(retSdata.requestSmhoxSt,~exSval); 
call 
rqSdeleteSmailbox(retSdata.respSmboxSt,~exSval); 
do 
i='l to 
7; 


call 
rqSdeleteSsemaphore( 


retScJata. i ntSserna (i) 
, 


~exSval) 
; 
end; 
call 
rqScJeleteSsegment(retScJataSt,0ex$val); 
return; 


end; 
/* 
of 
procedure 
*/ 
end 
startSandSfinish; 


C ODE 
AREA 
S IZ E 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
671 
LINES 
READ 
'l PROGRAM 
ERROR(S) 


022ClH 


"'00C'H 
0'lflQH 
1'034H 


544D 
('fJ 
~D 
52D 


IsrS-II 
PL/M-86 
X167 
COMPILATION 
OF 
MODULE 
QUEUE53~IOMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:queio.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:queio.plm 
PRINT(:F5:QUEIO.LST) 


DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE (4/25/80) 


queue$53~$io$module: 
do; 


This 
procedure 
is called 
by the 
I/O System 
to queue 
an 
I/O request 
to 
the 
534 
board. 
The 
function 
field 


in 
the 
IORS 
is 
used 
to determine 
what 
specific 
action 
to 
take. 
Module 
also 
contains 
a dummy 
cancel$534$io 
procedure. 


$ include (:f4:nucprm .ext) 
$SAVE 
NOLIST 
$include(:f4:common.lit) 
$SAVE 
NOLIST 
$include(:f4:nerror.lit) 


$SAVE 
NOLIST 
$include(:fl:pointr.ext) 
/* external 
declaration 
of 
pointerize 
procedure 
*/ 


$save 
nolist 
$ incl ud e (:f 1:d uib.l it) 
/* duib 
structure 
definition 
*/ 


$save 
nolist 
$ inc 1ud e (:f 1:i0 rs.l it) 
/* literal 
declaration 
for 
iors */ 


$save 
nolist 
$ incl ude (:f 1:retd ta .1 it) 
/* literal 
declaration 
of 
retSdata 
structure 
for 
initS534$io 
*/ 


$save 
nolist 


315 
316 


317 


io$534$task: 
procedure 
external; 
end 
io$534$task; 


declare 
begin$io$task$data 
byte 
external; 


queueS534$io: 
procedure(iors$t,duib$p,retSdataSt) 
reentrant 
public; 


declare 
(iors$t,ret$data$t) 
token, 
data$seg$p 
pointer, 
data$seg$p$o 
structure(offset 
word,base 
word) 
at(@data$segSp), 


IDDR 
literally 
'2AH', 


(duib$p,ret$dataSp,iorsSp) 
pointer, 
(duib 
based 
duibSp) 
dev$unit$infoSblock, 
(retSdata 
based 
retSdataSp) 
structure(retSpata$struc), 


(ioes 
})ased 
ior5~p) 
rOSrcquest:SrpsultSseqment, 


i.oStaskSt t.oken, 
unitSinfoSp 
pointer, 


unitSinfo 
baserl unltSinfoSp 
strurture(. 


us",rtSc~lcibyte, 
b a url S r'" t (' 
wo r ct) 
, 


i 
byte, 


rlumrnySt t.oken, 
p.xSval 
woro; 


320 
321 


322 
323 


iors$p=pointerize(iors$t); 
ret$data$p=pointerize(ret$data$t); 


if 
iors.funct 
> 
7 
then 
goto 
bad$request; 


325 
326 
327 


do; 
1* case 
0-- 
read 
*1 


iors.aux$p=ret$data$p; 
call 
rq$send$message( 


1* mbox 
*1 
ret$data.request$mbox$t, 
1* 
token 
*1 
iors$t, 
1* 
resp 
*1 
0, 
1* 
status 
ptr*1 
0ex$val); 
return; 
end; 


328 
329 


330 
331 
332 


do; 
1* case 
1-- 
write 
*1 


ior s.a ux$ p= ret$data$ 
p; 
call 
rq$send$message( 
1* mbox 
*1 
ret$data.request$mbox$t, 
1* 
token 
*1 
iors$t, 


1* 
resp 
*1 
0, 


1* 
status 
ptr*1 
@ex$val); 
return; 
end; 


333 
4 
334 
4 


335 
3 
336 
4 


337 
4 


338 
3 
339 
4 
340 
4 


341 
3 


342 
4 
343 
4 
344 
5 


do; 
1* case 
2--seek 
(illegal) 
*1 
goto 
bad$request; 
end; 


do; 
1* case 
3-- 
special 
(illegal) 
*1 
goto 
bad$request; 
end; 


data$segSp=@beginSIO$taskSdata; 
do 
i=0 
to 
1; 
ioStask$t= 
rq$create$task( 
1* priority 
*1 
150, 
1* 
entry 
pnt 
*1 @io$534$task, 


1* data 
seg 
*1 
data$segSpSo.base, 


1* 
stack 
ptr *1 0, 


1* stack 
size 
*1 
1* 
task 
flags 
*1 
1* 
status 
ptr *1 


50f'1, 
0, 
(ilexSval); 


345 
5 


346 
4 
347 
4 
348 
5 
349 
5 
350 
4 
351 
4 


352 
4 
353 
4 


354 
4 


355 
4 


356 
4 


unitSinfoSp=duib.unitSinfo$p; 
do 
i=0 
to 
3; 
output(retSdata.usart$cmdSport(iors.unit»)=0; 


end; 
output(retSdata.usartScmdSport(iors.unit»)=40H; 
output(ret$data.usartScmdSport(iors.unit»= 
unitSinfo.usartScmd; 
output(retSdata.usart$cmdSport(iors.unit)=27H; 
output(retSdata.IO$base+0CH)=O; 
1* select 
cntrl 
blk 
*1 


output(ret$data.timer$cmd$port(iors.unit)= 
retSdata.timer$cmd(iors.unit); 
output(ret$data.timer$load$port(iors.unit»= 
low( uni t$ info .baud$rate); 


output(ret$data.timerSloadSport(iors.unit»)= 
high (uni t$ info .baudSrate); 


359 
360 
361 


362 


367 
4 
368 
4 


369 
3 
370 
4 
371 
4 


372 
3 
373 
4 
374 
4 
375 
3 
376 
2 
377 
2 


378 
2 


379 
2 


380 
2 


381 
2 
382 
2 


383 
1 


384 
2 


385 
2 


dummySt=rqSreceiveSunits( 
1* serna *1 
retSdata.intSsema( 
2 * 
iors.unit), 
1* 
units 
*1 1, 


1* timeSout 
*1 
0, 


1* status 
*1 
@exSval); 
i=input(retSc1ata.usartSdataSport( 
iors.unit 
»); 
goto 
okSsendSresp; 
end; 


1* 
send 
two 
copies 
of 
the 
detach 
request 
to 
the 
request 
mailbox. 


This 
will 
signal 
to 
two 
of 
the 
I/O 
tasks 
that 
they 
are 
to 
delete 
themselves 
*1 


call 
rqSsendSmessage( 
1* mbox 
token 
*1 
retSdata.requestSmboxSt, 
1* object 
token 
*1 
iorsSt, 


1* 
response 
*1 
retSdata.respSmboxSt, 


1* status 
*1 
@exSval); 
dummySt=rqSreceiveSrnessage( 
1* mhox 
token 
*1 
retSdata.resp$mbox$t, 


1* 
time$limit 
*1 
0FFFFH, 


1* 
response 
ptr *1 
@dummySt, 
1* status 
ptr *1 
@exSval); 
call 
rqSsend$message( 


1* rnbox token 
*1 
ret$data.request$mbox$t, 


1* object 
token 
*1 
iorsSt, 


1* 
response 
*1 
retSdata.resp$rnboxSt, 


1* 
status 
*1 
@exSval); 
dummySt=rqSreceiveSrnessage( 
1* mbox 
token 
*1 
ret$data.resp$mboxSt, 
1* 
timeSlimit 
*1 
0FFFFH, 


1* 
response 
ptr *1 
@durnmySt, 


1* 
status 
ptr *1 
@exSval); 
goto 
ok$send$resp; 
end; 


do; 
1* case 
6-- 
open 
*1 
goto 
ok$send$resp; 
end; 


do; 
1* case 
7-- 
close 
*1 


goto 
ok$send$resp; 
end; 
end; 
1* do 
case 
*1 


return; 
bad$request: 
iors.status=IDDR; 
goto 
sendSresp; 
ok$sendSresp: 
iors.status=ESOK; 
send$resp: 


call 
rqSsend$message(iors.respSmbox,iorsSt,0,@ex$val); 
return; 
end; 
1* 
proced ure * I 


cancelS~34 
Sio: 
procedure 
(iorsSt ,duib$p,ret$data$t) 
publ ic; 


declare 
(iorsSt,ret$dataSt) 
token, 
duibSp 
pointer; 


386 
387 
end; 
end 
queueS534SioSmodule; 


CODE 
AREA 
SIZ E 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
729 
LINES 
READ 
o 
PROGRAM 
ERRORISl 


020CH 
0000H 
0000H 
0038H 


524D 
rm 
flD 
560 


OBJECT 
MODULE 
PLACED 
IN 
:Fl:int534.0BJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:int534.plm 
PRINT(:Fl:INT534.LST) 
DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE(5/28/80) 


$nointvector 
Interrupt$534$module: 
do; 


INT$534$TASK 
and 
INT$534$HND: 
PUBLIC 
PROCEDURES: 


This 
module 
contains 
the 
interrupt 
handler 
and 
the 
interrupt 


task 
for 
the 
534 
board 
interrupt. 
The 
handler 
simply 
calls 


signal$interrupt 
and 
the 
task 
reads 
the 
ISR 
on 
the 
534 


board's 
8259 
and 
sends 
a 
unit 
to 
one 
of 
eight 
interruptS 


pending 
semaphores 
to 
signal 
the 
occurrence 
of 
the 
event. 


$ incl ud e( :f 2:nucprm.ext) 
$SAVE 
NOLIST 
$ inc 1ud e (:f 1:retd ta .1 it) 
/* literal 
declaration 
of 
ret$data 
structure 
for 
init$534$io 
*/ 


$save 
nolist 
$include(:f2:common.lit) 
$SAVE 
NOLIST 


declare 
begin$int$534$data 
byte 
pUblic, 
g$ret$data$p 
pointer 
external, 
IO$base$addr 
byte 
external, 
int$level 
word 
external; 


d ecl are 
1 word, 
ex$val 
word; 


311 
312 
313 
314 


315 


316 


l=rq$get$level(@ex$val); 
call 
rq$signal$interrupt(l,@ex$val); 
return; 
end; 


declare 
IO$534$base 
byte, 
int$534$level 
word, 
ret$data$p 
pointer, 
ret$data 
based 
ret$data$p 
structure(ret$data$struc) 
, 


c$level 
byte, 
ex$val 
word, 
eoi 
literally 
'20H'; 


317 
318 
319 
320 


IO$S34$base=IO$base$addr; 
int$534$level=int$level; 
ret$data$p=g$ret$dataSp; 
call 
rq$set$interrupt( 


/* level 
*/ 
int$534$level, 


/* flags 
*/ 
1, 


/* entry 
point 
*/ 
/* data 
segment 
*/ 
/* status 
ptr 
*/ 


interrupt$ptr 
(int$534$hnd) 
, 


0, 
@ex$val); 


321 
322 
323 
324 
325 
326 
327 
328 


do 
forever; 
call 
rq$wait$interrupt(int$534$leve1,@ex$va1); 


output(IO$534$base+8)=0CH; 
c$leve1=input(IO$534$base+8) 
and 
07H; 
ca 11 
rq$ sendS uni ts (ret$data. 
int$ serna(c$leve1) 
,1,@ex$va1) 
; 


output(IO$534$base+8)=EOI; 
end; 
/* of 
do 
forever 
*/ 
end; 
/* of 
procedure 
*/ 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 
541 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


00B5H 
0000H 
0005H 
0026H 


1810 
00 
5D 
380 


ISIS-II 
PL/M-86 
Xl67 
COMPILATION 
OF 
MODULE 
I0534TASKMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:FI:iotask.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:FI:iotask.plm 
PRINT(:F5:IOTASK.LST) 
DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE(4/25/80) 
, 
' 


io$534$task$module: 
do; 


This 
task 
receives 
IORS 
segments 
from 
the 
queueSio 
procedure 
and 
performs 
the 
necessary 
input 
or 
output 
operations 
on 
the 
iSBC 
534 
board. 


$include(:f4:common.lit) 
$SAVE 
NOLIST 
$include(:fl:pointr.ext) 
/* external 
declaration 
of 
pointerize 
procedure 
*/ 
$save 
nolist 
$ include (:f 4:nucprm. ext) 
$SAVE 
NOLIST 
$include(:f4:nerror.lit) 


$SAVE 
NOLIST 
$ inc 1ud e (:f 1:retd ta .1 it) 
/* literal 
declaration 
of 
retSdata 
structure 
for 
initS534Sio 
*/ 


Ssave 
nolist 
$ inc 1ud e (:f 1: i0 rs.l it) 
/* literal 
declaration 
for 
iors 
*/ 
$save 
nolist 


declare 
begin$io$task$data 
byte 
public, 
reqSmboxSt 
token 
external, 
f$detach$device 
literally'S', 
f$read 
literally 
'0', 
f$write 
literally 
'1'; 


declare 
iors$t 
token, 
iorsSp 
pointer, 
iors 
based 
iors$p 
IOSrequestSresultSsegment, 
ex$val 
word, 
resp$t 
token, 
buff$p 
pointer, 
buf 
based 
buffSp 
(1) 
byte, 
i 
wo rd, 
unit 
byte, 
retSdataSp 
pointer, 
retSdata 
based 
retSdata$p 
structure(retSdataSstruc) 
, 
cSval 
word; 


317 
318 


do 
forever; 
iors$t:rq$receive$message(reqSmboxSt,0FFFFH,~resp$t,@ex$val); 


/* check 
for 
non-existence 
of 
mailbox. 
IF 
last 
device 
has 
been 
detached 


the 
mailbox 
will 
be 
deleted 
In 
this 
case, 
delete 
thyself 
*/ 


if 
ex$val: 
ESexist 
then 
call 
rq$delete$task(0,@ex$val); 
iorsSp:pointerize(iors$t); 


319 
320 
321 


322 
323 
324 
325 
326 


buffSp=io~s.buffSp; 
unit=io~s.unit; 
io~s.actual=fl; 
i="'; 
~etSdataSp=io~s.auxSp; 


327 
328 
329 


if 
io~s.funct 
= 
fSdetachSdevice 
then 
do; 
call 
~gSsendSmessage1 


1* mbox 
token 
*1 
~espSt, 


1* object 
token 
*1 
io~sSt, 


1* 
~esponse 
token 
*1 
"', 


1* 
status 
pt~ *1 
@exSval); 
call 
~gSdeleteStask(0,@exSval); 
end; 


330 
331 


332 
333 
334 


if .io~s.funct= 
fS~ead 
then 
do 
while 
io~s.count 
>0; 
cSval=~gS~eceiveSunits( 


1* sema 
*1 
~etSdata.intSsema(2*unit), 
1* units 
*1 
1, 


1* 
time 
*1 
0FFFFH, 


1* 
status*1 
@exSval); 


335 
336 
337 
338 
339 


buf(i)=input(~et$data.usa~tSdataSpo~t(unit) 
and 
fl7FH; 


i=i+l; 
io~s.count=io~s.count-l; 
io~s.actual=io~s.actual+l; 
end; 


34'" 
341 
342 


else 
if 
io~s.funct= 
fSw~ite 
then 


do 
while 
io~s.count 
>0; 


cSval=~g$~eceiveSunits( 


1* sema 
*1 
~etSdata.intSsema(2*unit+l), 
1* 
units 
*1 1, 


1* 
time 
*1 
flFFFFH, 


1* status*1 @exSval); 
output(~etSdata.usa~tSdataSpo~t(unit»=buf(i); 
i=i+l; 
io~s.count=io~s.count-l; 
io~s.actual=io~s.actual+l; 


end; 


io~s.status=ESOK; 
io~s.done=TRUE; 
call 
~gSsendSmessage(io~s.~espSmbox,io~sSt,0,@exSval); 
end; 
1* of 
do 
fo~eve~ 
*1 


343 
344 
345 
346 
347 


349 
350 
351 


352 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
624 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


END 
OF 
PL/M-86 
COMPILATION 


IH8DH 
000flll 
0flfllH 
0028H 


397D 
flD 
ID 
4flD 


ISIS-II 
PL/M-86 
X167 
COMPILATION 
OF 
MODULE 
INIT534HW 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:inithw.OBJ 
COMPILER 
INVOKED 
BY: 
plm86 
:Fl:inithw.plm 
PRINT(:F5:INITHW.LST) 
DEBUG 
COMPACT 
OPTIMIZE(2) 
ROM 
DATE(4/25/8~) 


2~ 
2 
21 
2 
22 
2 


23 
2 
24 
3 
25 
3 
26 
3 
27 
3 
28 
2 


29 
2 


3~ 
2 
31 
2 
32 
2 
33 
1 


init$534$hw: 
do; 


This 
procedure 
initializes 
the 
iSBC 
534 
hardware 
and 
sets 
up 
the 
device 
dependent 
fields 
of 
the 
retSdata 
segment 
which 
will 
be 
used 
by 
the 
queueSio 
procedures. 


Sinclude(:f4:common.lit) 
$SAVE 
NOLIST 
S inc 1 ud e (:f 1:retd ta .1 it) 
/* 
literal 
declaration 
of 
retSdata 
structure 
for 
initS534Sio 
*/ 


$save 
nolist 


declare 
ret$dataSp 
pointer, 
retSdata 
based 
retSdataSp 
structure(retSdataSstruc), 


(base,i) 
byte; 


base=retSdata.ioSbase; 
output(base+~FH)=~; 
/* 
board 
reset 
*/ 


output(base+~DH)=~; 
/* 
select 
data 
block 
*/ 
output(base+8)=16H; 
/* 
output 
ICWI 
*/ 
output(base+9)=~; 
/* 
output 
ICW2 
*/ 


output(base+9)=~; 
/* 
output 
mask 
word 
*/ 


/* 
attachSdevice 
calls 
will 
initialize 
usarts 
and 
timers 
*/ 
/* 
set 
up 
tables 
of 
port 
addresses 
for 
use 
by 
queueSio 
procs 
*/ 


ret$data.timerScmd(~) 
,retSdata.timerScmd(3)=36H; 
retSdata.timerScmd(1)=76H; 
retSdata.timerScmd(2)=~B6H; 
do 
i=~ 
to 
3; 
retSdata.usartScmdSport(i)=base+2*i+l; 
retSdata.usartSdataSport(i)=base+2*i; 
retSdata.timerSloadsport(i)=base+i; 
end; 
retSdata.timerSloadSport(3)=base+4; 
retSdata.timerScmdSport(~), 
retSdata. 
t imerScmdSport 
(1) , 
retSdata.timerScmdSport(2)=base+3; 
retSdata.timerScmdSport(3)=base+7; 
return; 
end; 
end 
initS534Shw; 


MODULE 
INFORMATION: 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZF 


77 
LINES 
READ 
~ 
PROGRAM 
ERROR(S) 


""E4H 


l'I"~l'IH 
l'IOMH 
(l0~8H 


228D 
OD 
0D 
8D 


APPENDIX 
B 
Configuration Listings/Worksheets 


FREE 
SPACE 


ROOT 
JOB 


APPLICATION 
JOB 


COMMUNICATIONS 
JOB 


1/0 SYSTEM 


NUCLEUS 


INTERRUPT 
VECTOR 


Fl!l: 
LINK86 
& 
:Fl:NUC86.LIB(NENTRY), 
& 


:Fl:NUC86.LIB 
& 
TO 
:Fl:NUCLUS.LNK 
MAP 
PRINT(:Fl:NUCLUS.MPl) 
NAME(NUCLEUS) 


:Fl!l: 
LOC86 
& 


:Fl:NUCLUS.LNK 
TO 
:Fl:NUCLUS 
MAP 
PRINT(:Fl:NUCLUS.MP2) 
SC(3) 
& 


RESERVE(l!l TO 
7FFH) 
SEGSIZE(STACK(l!l)) 
& 
ORDER (CLASSES (CODE,DATA,STACK,MEMORY») 
& 
OBJECTCONTROLS(NOLINES,NOCOMMENTS,NOPUBLICS,NOSYMBOLS) 


ios(date,origin) 
Sample 
I/O 
System 
.csd 
file 
to 
link 
and 
locate 
an 
I/O 
System. 


This 
.csd 
file 
assumes 
the 
I/O 
System 
configuration 
module 
is 
iocnfg .a86 
(found 
on 
the 
release 
diskette) 
• 


The 
origin 
parameter 
sets 
the 
low 
address 
of 
the 
I/O 
System; 
all 
the 
segments 
are 
contiguous 
in memory. 


asm86 
:fl:iocnfg.a86 
date(%0) 
link86 
& 
:fl:ios.lib(ioinit), 
& 


:f1: iocnfg .obj, 
& 
:f1:ios.l ib, 
& 


:f1:rpifc.lib 
& 
to 
:f1:ios.lnk 
map 
print(:f1:ios.mpl) 
loc86 
:f1:ios.lnk 
to 
:f1:ios 
map 
sc(3) 
print(:fl:ios.mp2) 
& 
oc(no1i,nopl,nocm,nosb) 
& 
order(classes(code,data,stack,memory» 
& 
addresses(classes(code(%l») 
& 
segsize(stack(0» 


1ink86 
& 


:f1:ftinit.obj, 
& 


:f1:listen.obj, 
& 
:f1:worker.obj, 
& 
:f1:pointr.obj, 
& 
:f1:rpifc.lib 
& 
to 
:f1:apexl.1nk 
map 
print(:f1:apexl.mpl) 


I 


loc86 
:f1:apex1.lnk 
to 
:fl:apexl 
map 
sc(3) 
print(:fl:apex1.mp2) 
& 


oc(no1i,nopl,nocm,nosb) 
& 
order(classes(code,data,stack,memory» 
& 
addresses(classes(code(%l») 
& 
segsize(stack(0» 


, 
link86 
& 
:f1:cminit.obj, 
& 
:f1:comm.lib, 
& 
:f1:pointr.obj, 
& 
:f1:rpifc.lib 
& 
to 
:f1:comm.lnk 
map 
print(:f1:apexl.mp1) 
loc86 
:f1:comm.1nk 
to 
:f1:comm 
map 
sc(3) 
print(:fl:comm.mp2) 
& 


oc(noli,nopl,nocm,nosb) 
& 
order (classes (code,data 
,stack ,memory» 
& 
addresses(classes(code(%l») 
& 
segsize(stack(0» 


l'l77EH 
1l'lE4H 
PUB 
INITDEVICETABLES 
l'l77EH 
l'lFBCH 
PUB 
NAMEDDELETE 
l'l77EH 
l'lEB3H 
PUB 
DECRUSECOUNT 
l'l77EH 
l'lE51H 
PUB 
UNLINKCONN 


l'l77EH 
l'lCA8H 
PUB 
NAMEDCHANGEACCES 
l'l77EH 
filB5AH 
PUB 
ATTACHNAMEDFILE 


-5 
~l'l77EH 
l'l73EH 
PUB 
ATTACHDEVICETASK 
l'l77EH 
l'l574H 
PUB 
I LLEGA LFUNCT 
l'l77EH 
l'll'l3EH 
PUB 
RQA 105 
INITTASK 
l'l77EH 
l'll'l06H 
PUB 
COPYRIGHT 


SEGMENT 
MAP 


START 
STOP 
LENGTH 
ALIGN 
NAME 
CLASS 


"'77E"'H 
1453EH 
CD5FH 
W 
CODE 
CODE 


1454"'H 
145FFH 
l'll'lCl'lH 
W 
REQ 
TABLE 
CODE 
1461HlH 
146DFH 
"''''El'lH 
W 
lOS-TABLE 
CODE 


-+146El'lH 
14745H 
l'll'l66H 
W 
DATA 
DATA 
14746H 
14746H 
l'll'l"'0H 
W 
STACK 
STACK 
1475l'lH 
1475l'lH 
l'll'll'll'lH 
G 
??SEG 


-'1475BH 
14750H 
l'll'll'll'lH 
W 
MEMORY 
MEMORY 


Locate Map for 1/0 System 


(The "-." 
indicates entries for job macros and memory map) 


1475H 
e79EH 
PUB 
SETUP544 
1475H 
l'l6C5H 
PUB 
PACKETINPUT 


1475H 
l'l5B5H 
PUB 
INDEX 
-.1475H 
l'l572H 
PUB 
COMMINITTASKENTRY 


-ESS 


SEGMENT 
MAP 


START 
STOP 
LENGTH 
ALIGN 
NAME 
CLASS 


1475"'H 
15BCDH 
147DH 
W 
CODE 
CODE 


~15BD"'H 
1 7l'lD2H 
15l'l2H 
W 
DATA 
DATA 
17"'D2H 
1 712EH 
"''''4CH 
W 
STACK 
STACK 
1713"'H 
1 713l'lH 
"'l'l"'l'lH 
G 
??SEG 
~1713"'H 
1 713"'H 
l'll'll'l"'H 
W 
MEMORY 
MEMORY 


Locate Map for Communications 
Job 


17D6H 
l'l3B5H 
PUB 
BEGINLISTENERTASKDATA1713H 
l'l153H 
PUB 
POINTERIZE 
~1713H 
l'l1l2H 
PUB 
INITTASKENTRY 
1713H 
l'l4l'llH 
PUB 
WORKERTASK 


SEGMENT 
MAP 


START 
STOP 
LENGTH 
ALIGN 
NAME 
CLASS 


1713"'H 
1 7D59H 
"'C29H 
W 
CODE 
CODE 


17D6"'H 
17E28H 
"'l'lC8H 
W 
DATA 
DATA 
17E3"'H 
1 7E9AH 
0l'l6AH 
W 
STACK 
STACK 


Macro call: 
SYSTEM (system parameters) 


Number of calls required: 
exactly one 


CONFIGURATION FILE NAME 


FORMAT: 


suggested 
parameter 
type 
default 
value 
-- 


%SYSTEM 
(nucleus_entry, 
base 
80:0 
rod_size, 
word 
(0) 
..1il- 


min_trans_size, 
work 
(64) 
..M- 


debugger, 
see note 
(A) 
1 
_N__ 


default_e_h_provided, 
see note 
(N) 
2 
_N__ 


mode) 
word 
1 


NOTES: 


1. 
Valid entries for the debugger parameter include: 


A 
Debugger available 
N 
No debugger available 


2. 
Valid entries for the default_e_h_provided 
parameter include: 


Y 
Yes 
D 
Debugger 
N 
No 


(start_base, 
end_base, 
type) 


base 
base 
see note 
1 


1. 
The type parameter is reserved for future use. Enter 
the character U for this parameter. 


suggested 
default 


_0__ 


1900 


FORMAT: 


suggested 


parameter 
type 
default 
value 


%JOB 
(directory_size, 
word 
(0) 
0 
pool_min, 
word 
OFFFF 
pool_max, 
word 
(OFFFFH) 
OFFFF 
max_objects, 
word 
FFFF 
max_tasks, 
word 
FFFF 
max_job_priority, 
byte 
129 
exception_hand ler_e ntry, 
addr 
(0:0) 
0:0 
exception_hand ler_m ode, 
byte 
(1) 
1 
job_flags, 
word 
(0) 
0 
init_task_priority, 
byte 
1713:112 
data.-segment_base, 
base 
(0) 
1706 
stacLpoi 
nter, 
'addr 
(0:0) 
0:0 
stacLsize, 
word 
(512) 
512 
tasLflags) 
word 
(0) 
0 


%sab(0,1900,U) 
%job(0,300h,0FFFh,0ffffh,0ffffh,0,0:0,0,0,128,77e:3e,146e,0:0,5l2,0) 
%job(0,lFFH,0FFFH,0FFFFH,0FFFFH,128,0:0,0,0,13l,1475:572,15bd,0:0,400,0) 
%job(~,300H,0FFFFH,0FFFFH,0FFFFH,128,0:0,1,0,130,17l3:l12,17d6,0:0,400H,0) 
%system(80,10,64,N,N,1) 


This 
submit 
file 
fsys 
fin 
fout 
con fig 
file 
date 


assembles 
the 
CTABLE 
module, 
where: 
the 
system 
disk 
containing 
ASM86 
the 
source/input 
disk 
(Fl 
is 
assumed) 
the 
object/listing/output 
disk 
the 
path-name 
of 
the 
configuration 
file 
the 
date 


copy 
%3 
to 
:fl:config.cnf 
b 


:%0:asm86 
:%l:ctable.a86 
pr (:%2:ctable.lst) 
oj (:%2:ctable.obj) 
date(%4) 
& 
xref 
debug 
ep 


This 
submit 
file 
links 
the 
Root-Job, 
where: 
fsys 
the 
system 
disk 
containing 
LINK86 
fin 
the 
source/inp'lt 
disk 
fout 
the 
object/listing/output 
disk 


:%ril:link86 :%l:croot.lib(root),& 
:%2:ctable.obj,& 
:%l:croot.lib 
& 
to 
:%2:rootjb.lnk 
map 
pr(:%2:rootjb.mpl) 


This 
submit 
file 
locates 
the 
Root-Job, 
where: 
fsys 
the 
system 
disk 
containing 
LOCB6 
fin 
source/input 
disk 
fout 
object/listing/output 
disk 


NOTE: 
BE 
SURE 
TO 
REPLACE 
THE 
"?7???" 
BELOW 
WITH 
THE 
APPROPR lATE 
ADDRESS 
THE 
ROOT-JOB 
IS TO 
BE 
LOCATED 
AT! ! 


:%0:loc86 
:%2:rootjb.lnk 
to 
:%2:rootjb 
& 
map 
pr(:%2:rootjb.mp2) 
sc(3) 
& 
name(ROOT 
JOB) 
oc(nocm,noli,nopl,nosb) 
& 
segsize(stack(200h») 
& 
order (classes (data ,stack ,memory,code)) 
& 
addresses(classes(data(12C00H))) 
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Resource Contention. 
. . . . . . . . . . . . . . . .. 
2-136 
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As computer systems become more complex, a recurring 
need occurs to use multiple processing units. Multiproc- 
essing can, in many applications, 
increase throughput, 


enhance reliability, or create a more modular design ap- 
proach. Intel's single board computer family provides a 
convenient tool for creating a multiprocessing 
environ- 


ment when combined 
with the Multibus 
system bus 
architecture. 
The use of the Intel RMXlSO Real-Time 


Multitasking 
Executive simplifies the creation of modu- 


lar designed system architectures. 
It also allows more 


efficient use of the processor's 
capabilities 
by sharing 


them between several independent 
tasks. 


This application 
note provides insight as to the tech- 


niques which can be used to create a multiprocessing 
system which is fully compatible 
with the use of Intel's 
RMX/SO multitasking 
executive. 
Both hardware 
and 


software capabilities of the Intel single board computers 
are discussed. 
For example, 
an explanation 
of both 


serial and parallel 
priority 
resolution 
techniques 
for 


creating a multimaster 
system are included. 
The tech- 


niques for using the bus lock features to provide mutual 
exclusion of resources and for creating both hardware 
and software semaphores 
is also a part of the applica- 


tion note. Many of the multiprocessing 
principles are 


combined to create the capability of transferring 
mes- 


sages between tasks operating 
on different 
processor 


boards, thus creating a combined multiprocessor/multi- 
tasking operating system. 


A potentially 
complex application 
is examined and the 


benefits gained by using a multiprocessing 
approach are 


discussed. The various requirements 
defined from the 
application 
are used to demonstrate 
the available fea- 


tures 
of the Intel product 
line as applied 
to multi- 


processing. 


Extensions 
of the features are developed where neces- 


sary to create a complete solution to the design exercise. 
For example, a capability is provided for a flexible oper- 
ator 
interface 
to the system which provides 
certain 


global functions to the multiple processors. 
This capa- 


bility, called the Common 
System Module (CSM), in- 


cludes the required 
drivers for disk drives and for an 


operator's 
CRT terminal. 
The operator 
interface 
in- 


cludes a BASIC interpreter 
capability. 


Finally, 
the application 
is modularized 
and the tech- 


niques which make the control 
sol~tion easily imple- 


mented 
using multiprocessing 
techniques 
are demon- 


strated. 


It is assumed that the reader has a fundamental 
knowl- 


edge of multitasking 
operating 
system concepts and is 
familiar 
with the use of PL/M-SO as a language 
on 


Intel's single board computers. 
In addition, 
a working 


knowledge of BASIC is assumed. The reader not having 
these skills should refer to the documents referenced in 
the 
Related 
Publications 
section 
of this application 


note. 


Multiprocessing 
Strengths 


The most common use of multiprocessing is to offload a 
main processor of low level duties in order to increase 
system throughput. 
Significant 
examples of this tech- 


nique are the use of Intel UPI devices such as the S741A 
and the use of intelligent slave boards such as the Intel 
iSBC 544 Intelligent Communications 
Controller or the 
iSBC 569 Intelligent Digital Controller. 
The techniques 
which are developed 
in this application 
note do not 


apply to these multiprocessor 
implementations 
because 


they have been extensively covered in other application 
notes. 


Processors 
can be offloaded 
of other 
than low level 


functions in complex systems. Just as a real-time appli- 
cation can be divided into functional 
tasks, these tasks 
can be grouped according to function. Each function or 
class of tasks can be assigned to a single board com- 
puter. 
The system throughput 
can thus be increased 


since tasks can now run concurrently 
and, 
using the 


software pwcedures 
developed in this application 
note, 
can communicate 
among 
themselves 
as though 
they 
were operating 
on the same processor 
board. 
Single 


board computers operating in this manner are known as 
multimaster 
computers. 


A second instance where multiprocessing 
can be con- 
sidered in a system design is in those cases where the 
operational 
integrity can be enhanced 
by having more 


than one processor. 
In these cases, the application 
may 


require that no single component 
failure can completely 


cause the system to fail. Multiprocessing 
provides this 


feature by allowing control of those operations 
associ- 


ated with a processor board to continue to function even 
when another 
board has failed. In many cases, provi- 


sion can be made to have the remaining board or boards 
take over some or all of the functions which were associ- 
ated with the failed board. 
Even though 
this would 


result in slower throughput, 
critical functions would still 


be performed 
by the computer system. 


Another 
benefit is the modular 
system design and ex- 


pansion 
capabilities 
which can be realized 
by using 


multiprocessing 
in industrial control applications. 
Here, 


it has been found that process definitions 
and opera- 


tions· tend to be rather dynamic. 
As products 
are im- 


proved or new ones added to the operation, 
the control 
system must be capable of being updated to conform to 
the new product 
flow. It is common to have an added 
requirement that the changes in a process must be made 
with no impact on other processes being controlled 
by 


the same system. Using a multi master board for each 
process allows this operation 
to be easily implemented. 


Process Example 


To emphasize the advantages which can be gained using 
multiprocessing, 
consider the chemical production 
facil- 


ity whose process flow is shown in Figure I. This prod- 
uct flow chart is typical of many found in the chemical 
industry where a product is manufactured 
from several 


raw ingredients which are purchased. This type of prod- 
uct lends itself well to automation. 
Consider, then, the 


approach to designing a control system which will oper- 
ate in the facility which has been defined. 


The first design goal is to define global system tasks 
which need to be performed by the system. Examination 
of the flow diagram in Figure I might lead one to define 
the system tasks as: 


I) Inventory control 
2) Quality control 
3) Production 
scheduling 
4) Weighing ingredients 
5) Mixing ingredients 
6) Drying and forming product 
7) Packaging 


The choice just made certainly is not the only valid pos- 
sibility but it should be adequate to allow the design dis- 
cussion to continue. 


The system tasks listed tan 
be grouped 
according 
to 


supervisory'and 
control 
tasks. 
Items 1 through 
3 fall 


into the supervisory 
category 
and items 4 through 
7 


belong to control category. This breakdown also groups 


the items according to the type of programs which will 
be required to implement the functions. 


The grouping of system functions 
into categories sug- 


gests that a multimaster 
approach 
is a good design path 
to create a system solution. Five multimaster boards are 
suggested, one for the supervisor and four boards which 
provide the control capabilities. This functional group- 
ing is seen in Figure 2. 


The examination 
of the product flow and system inter- 


actions shown in Figure I indicate that extensive com- 
munications 
are required between the various boards of 


the system. In addition, 
several tasks are required 
on 
each multimaster 
board 
and communications 
are re- 


quired between t~ese tasks. 


Intel's RMX/SO Real-Time Multitasking Executive pro- 
vides a simple method of handling the on-board 
com- 


munication 
operations 
by supporting 
the transmission 


and receipt of messages for data communication 
and 


synchronization. 
After 
a discussion 
of the hardware 


features which support multiprocessing, 
the application 


note will deal with the extension of the RMX/SO nucleus 
to support the transmission 
of messages between tasks 


which reside on different single board computers. 


-------------- 
- 
.---------- 


II. MULTIBUS™ MULTITASKING 
OPERATIONS 


The interactions of the various multimaster board func- 
tions occur via the medium of the Multibus system bus. 
This bus structure· is designed to easily support the use 
of more than one master processor in a system. Subse- 
quent paragraphs 
explain in some detail the features of 


the Multibus system bus which allow multimaster opera- 
tions 
when used with multimaster 
compatible 
single 


board computers. 


Bus Priority Resolution 
Lines 


The Multibus system bus uses seven control lines to sup- 
port the bus priority resolution techniques. 
Before con- 


tinuing with a discussion of these techniques, the reader 
should be provided with a definition of these lines and 
their functions. 
These lines are defined in subsequent 


paragraphs. 
One line is used for the system clock. It is: 


BCLKI 
Bus Clock; the negative edge of BCLKI is used 
to synchronize bus priority resolution circuits. 
BCLKI 
is asynchronous 
to the CPU clock. It 
has a 100 ns minimum period and a 35 to 65 
percent duty cycle. 


All Intel single board computers 
which are capable of 


being used as a bus master can provide this clock signal. 
In a multiple processor 
application, 
it is necessary to 


select only one board which is to actually supply this sig- 
nal to the system bus. On all other processor boards, 
this signal must be disabled by removing the jumpers as 
indicated in the appropriate 
Hardware Reference Man- 


ual (HRM). 


Several bus signals are dedicated to providing informa- 
tion as to the status of the bus to processors which are 
attempting to obtain control for their own data transfer. 
These are defined to be: 


BPRNI 
Bus Priority 
In Signal; indicates to a request- 


ing bus master board that no higher priority 
board 
is requesting 
use of the system bus. 
BPRNI is synchronized with BCLK/. 
The sig- 


nal is not bused on the backplane and must be 
generated and connected by the user as will be 
seen. 


BUSYI 
Bus Busy Signal; an open collector line driven 
by the current bus master to indicate that the 
bus is currently 
in use. BUSYI prevents 
all 


other potential 
masters from gaining control 


of 
the 
bus. 
BUSYI 
is synchronized 
with 


BCLK/. 


CBRQI 
Common 
Bus Request; an open-collector 
line 


which is driven by all potential bus masters and 
is used to inform the current bus master that 
another 
device 
wishes 
to 
use 
the 
bus. 
If 


CBRQI 
is high, it indicates to the current bus 


master that no other master is requesting the 
bus, and therefore, 
the present master can re- 


tain the bus control. 
This saves the bus ex- 


change overhead which would be required to. 
release and again re-acquire control of the bus. 


The timing relationship 
of these signals can be seen in 


Figure 3. Note that some type of bus request signal is 
generated by the master wishing to assert control of the 
system bus. Through 
some type of logic, a determina- 
tion must be made as to the effect that the requesting 
master has the highest priority. If so, the logic informs 
the requesting master by setting the BPRNI signal low. 
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Two signals are generated 
by single board 
products 


designed to be bus masters. These signals are used to 
generate the request signal. The request lines provided 
are known as: 


BPROI 
Bus Priority 
Out Signal; used with serial bus 


priority resolution schemes. BPROI 
is passed 


to the BPRNI input of the master module with 
the next lower priority. 
BPROI 
is synchro- 


nized with BCLKI 
and is not bused on the 


backplane. 


BREQI 
Bus Request Signal; used with a parallel bus 
priority 
network 
to indicate that a particular 


master board requires the use of the bus for 
one or more data transfers. 
BREQI is synchro- 


nized with BCLK/. 
It is not bused on the back- 
plane. 


The most easily implemented 
technique for supporting 


bus priority 
resolution 
is the serial or the daisy chain 


method. 
In 
this 
method, 
each 
board 
examines 
its 


BPRNI line. If the line is low and the master desires to 
use the system bus, it may do so. Internal board logic 
then places the BPROI line high to inhibit boards along 
the daisy chain with lower priority from gaining control. 
Any board 
in the chain with its BPRNI 
line high or 


which is requesting 
priority 
will set the BPROI 
line 


high. The wiring technique and logic of the serial prior- 
ity resolution scheme is shown in Figure 4. As long as 
the worst case propagation 
delay time between the high- 


est and the lowest potential bus master does not exceed 
30 ns, the technique 
provides 
a simple and effective 


method for resolving bus contention problems. Because 
of logic delays on iSBC boards, it has been found that 
the serial technique can only be used for a maximum of 
three bus masters when using a lOOns clock rate. 
If 


more 
masters 
are desired, 
either 
the clock must be 
slowed or the priority 
resolution 
technique 
must be 


modified. Thus, the BREQI line is used to support the 
second or parallel priority scheme. 


In a parallel 
priority 
network, 
all requests 
from bus 
masters 
are supported 
in parallel 
logic. Each master 


desiring use of the system bus places its BREQI line to a 
logical low condition. 
A parallel priority encoder chip 


such as a 74148 can be used to indicate the requestor 
having the highest priority. The output of the encoder 
can next be fed into a decoder network (74S138) to gen- 
erate 
a unique 
enable 
signal back 
to the processor 
board. 
These signals are fed back to the requesting 


boards as the BPRNI 
control line. The logic to perform 


this parallel 
resolution 
is not a part of current 
Intel 


Multibus backplanes, 
so it must, when required, be con- 


structed and supplied by the user. Figure 5 shows an 
implementation 
which can be used to support a twelve- 


slot cardcage such as can be obtained 
using the Intel 


iCS-80 
chassis. 
Since 
all bus 
priority 
requests 
are 


handled 
using parallel 
logic, additional 
potential 
bus 
masters may be added without adding to the signal delay 
time. Thus, the number of requests which may be re- 
solved is limited only by the number of available card 
slots on the Multibus system bus. 
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Resource Contention 


Even though the bus priority 
resolution 
networks 
de- 
scribed above provide against two or more bus masters 
taking control of the bus at the same time, they do not 
prevent one processor 
from examining and modifying 


data at the same time that another is operating on this 
data (this is true because data is only transferred 
in 8 or 


16-bit blocks and the bus may be used by another master 
between transfers). 
Some technique 
for inhibiting 
the 


contention 
of resources must be provided if true multi- 


processing is to be performed. 
Three candidates can be 
considered to support this exclusion process. The tech- 
niques required to support 
each are explored in subse- 


quent paragraphs. 


Single board computers 
provide the capability of lock- 


ing the system bus from access by other bus masters. 
This fe.ature is provided by means of a bus lockout f1ip~ 
flop which may be set or reset by writing to a dedicated 
I/O port on each board. This flip-flop has the effect of 
keeping the BUSYI active which keeps the master in 
control of the bus. In this way, a master assures that it 
has exclusive control of a bus common resource. In fact, 
it has exclusive control of all bus resources even though 
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it may be using but one of them. This drawback prohib- 
its other masters from using devices on the bus which 
are not in contention 
as well as those that are. In many 


systems, this potential delay can prohibit the use of bus 
locks in all but a few special applications. 


Mutual 
exclusion can easily be obtained 
by using the 


concept of a semaphore. 
A semaphore may be thought 
of as a type of traffic signal which can be used to pro- 
hibit access to certain roads or resources. When such a 
semaphore technique is used with microprocessors, 
it is 
referred to as a test-and-set operation. 
This means that 
the act of testing the semaphore 
not only returns the 


current 
status 
but also forces the semaphore 
to the 


"on" 
condition. 
If the returned status from the test in- 
dicated 
a previously 
cleared 
condition 
of the sema- 
phore, 
the resource 
associated 
with it is considered 


available for exclusive use. Since the semaphore is now 
set, all other masters testing it will find a busy condition 
and must wait until the user processor clears the sema- 
phore assocaited with the resource. 
Each time a proc- 


essor completes its operations 
on a shared resource, 
it 


clears the semaphore by writing a zero to it. 


In practice, 
two types of semaphores 
are commonly 


found, the hardware semaphore and the software sema- 
phore. The use of each is identical and follows the gen- 
eral concepts outlined in the preceding paragraphs. 


Hardware Semaphores 


Hardware semaphores are those which are implemented 
using physical hardware. 
Logic components 
are used in 
circuits which must be designed and constructed 
by the 


user. Currently, no Intel boards provide for this type of 
semaphore 
implementation. 
Hardware 
semaphores 


have the advantage over a software implementation 
of 
being faster and requiring 
less system bus time. The 


most common designs consider the semaphore as an I/O 
port 
although 
memory 
mapped 
designs are certainly 


feasible. 


Hardware semaphores are conceptually thought of as a 
Ootype flip-flop. A simplified diagram of a typical sem- 
aphore is seen in Figure 6(a). Examining the timing rela- 
tionships of Figure 6(b), it is seen that, if an initial state 
of a clear semaphore is assumed, when a master proces- 
sor reads the I/O port, a data value of "zero" 
will be 


returned. The hardware immediately sets the flip-flop to 
a logical "one" 
on the trailing edge of the read signal. 


Any subsequent 
reads will find the semaphore 
"set". 


When the user is finished with the resource, it can clear 
the flip-flop by performing 
a "write" 
operation 
to the 


I/O port. 
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The user can prevent contention of a system resource by 
incorporating 
a "wait 
for semaphore 
clear" 
into his 
program. 
For example, if a resource is protected 
by a 


semaphore 
at I/O port 35H, the following PL/M 
code 


could be used to protect the resource: 


I" WAIT FOR SEMAPHORE TO CLEAR, LOCK IT "I 
DO WHILE INPUT (035H) 
< > 
0; END; 


I" PERFORM OPERATIONS ON RESOURCE "I 


I" CLEAR SEMAPHORE TO ENABLE RESOURCE "I 
OUTPUT (035H) = 0; 


The hardware 
semaphore 
is seen to be an effective 
method 
of incorporating 
mutual exclusion in a multi- 
processing application. 
Its major asset is that it mini- 
mizes system bus overhead and assures maximum bus 
throughput 
by higher priority master devices. Its weak- 
ness is the requirement 
for the user to provide hardware 
to implement 
the semaphores. 
In many cases, the bus 
overhead incurred by continuous 
sampling of the sema- 
phore when it is busy can be eliminated by providing a 
system bus interrupt 
each time a semaphore is cleared. 


If this technique 
is used, a processor 
desiring a busy 


resource could enable the appropriate 
interrupt 
level, 
then wait until the semaphore is cleared by the current 
user. 


Software Semaphores 


The concept of software semaphores has long been used 
in programming 
applications. 
A byte of memory is re- 


served for the semaphore 
or flag and this byte is then 


tested by software programs to convey data. This imple- 
mentation 
is not valid for multiprocessor 
designs since 


there is nothing to prevent a second processor from test- 
ing and 
finding a semaphore 
clear while the first is 
attempting 
to set it. To be effective in multiprocessor 
systems, the software semaphore must exhibit the char- 
acteristics 
of the "test-and-set" 
hardware 
implemen- 
tation. 


Many Intel single board computers 
such as the iSBC 


86/12A 
board 
incorporate 
a special instruction 
prefix 


which provides the test-and-set feature. This prefix, the 
LOCK, causes the processor board to maintain control 
of the system bus while the byte or word operand 
is 
tested and set. PL/M-86 
incorporates 
a special instruc- 
tion which implements the software semaphore. The use 
of this instruction 
is: 


This instruction 
causes the processor board to lock the 
bus and place the new value into the specified memory 
location. 
The old value is returned 
to the calling pro- 
gram. Only then will the bus be unlocked. An example 
demonstrates 
how this provides mutual exclusion of a 
resource. 


Assume that a software semaphore, 
LOCK$BYTE has 
been declared. A value of I indicates that the resource is 


being used and is not available. A value of 0 indicates 
that the common resource is available to a task. If the 
function 
reference 
LOCKSET(@LOCK$BYTE, 
I) is 


executed, 
the 
value 
of 
I 
will 
be 
assigned 
to 


LOCK$BYTE. 
Furthermore, 
the old value of the sem- 


.aphore will be returned. 
If a value other than 0 is re- 


turned, the statement must be repeated as the resource is 
being used by another 
task. When a value of 0 is re- 


turned as the old value, the resource has been dedicated 
to the calling task. When the task is finished with the 
shared resource, 
a zero must be written to the sema- 
phore byte. 


A similar technique can be used with 8-bit single board 
computers. 
For 
example, 
consider 
the 
iSBC 
80/30 


board. 
Provision 
has been made to provide a bus lock 


condition when the CPU SOD (the SOD is a output data 
line unique to the 8085 processor which is normally in- 
tended to be used as a serial output line) is active. A task 
desiring to gain exclusive access to a common resource, 
can lock the bus, then test and set the semaphore 
flag; 


finally, the bus can be freed by clearing the SOD signal. 
An example will make this more clear. 


Consider 
the same semaphore 
which was used in the 


PL/M-86 
discussion. 
A task 
executing 
on an iSBC 


80/30 
board and desiring to use the protected resource 


would have code similar to the following: 


;" WAIT FOR RESOURCE AVAILABLE"; 


OLDVALUE = 1; 
DO WHILE OLDVALUE = 1; 


CALL S$MASK(OCOH); 
1* lock bus 
"; 


OLD VALUE = LOCK$BYTE;;" get old value 
"; 


LOCK$BYTE = I; 
;" set semaphore "; 


CALL S$MASK(04OH); 
;" unlock bus 
"; 


END; 


;" Unlock resource for other tasks to use "; 


LOCK$BYTE = 0; 
;" clear semaphore "; 


Other boards use a dedicated I/O port to control the bus 
lock feature. For example, the iSBC 80/24 single board 
computer 
has dedicated 
port 05 to control 
the lock. 


Writing a I to this port will lock the bus and writing a 0 
will unlock it. With this exception, the technique shown 
for the iSBC 80/30 
board 
will work when using the 


iSBC 80/24 processor board in a multiprocessing 
appli- 
cation. 


III. 
MULTIPROCESSOR 
COMMUNICA· 


TIONS 


For efficient operation 
of a system solution which uses 


more than one processor, 
a means must be found to 


transmit 
data between the system bus master boards. 


The data, so transferred, 
might be used to pass param- 


eters, to move data strings, or to synchronize events on 
the various boards. 
While it is not the intent of this 


application 
note to fully explain all possible techniques, 


it does provide 
some insight into the most common 


multiprocessor 
data transfer methods. 


After 
a short 
discussion 
of various 
transfer 
mecha- 
nisms, the techniques used in the RMX/SO 
nucleus are 


described. 
The 
descriptions 
provide 
a basis 
for the 


development 
of an extension 
to the 
nucleus 
which 


allows tasks to reside on multiple boards 
in a multi- 


master environment. 


The most straightforward 
technique 
to communicate 


between processors is the use of flags or semaphores to 
synchronize 
operations. 
The procedures 
used in this 
type of data transfer 
have been explained in previous 
paragraphs. 
As will be seen, this technique will be later 


combined 
with more complex methods to synchronize 


the transfer of data. 


A second type of communications 
which may be used 


involves creating 
and maintaining 
data 
queues. 
This 
method was created to support a special case of multi- 
processing, 
the use of intelligent 
slaves. The creation 


and support 
of data queues has been thoroughly 
de- 


tailed in an Intel application 
note, AP-53, 
Using the 


iSBC 544 Intelligent 
Communications 
Controller. 
It 


should be noted that, even though created for intelligent 
slaves, the technique is certainly applicable to the gen- 
eral case of multiprocessor 
communications. 


The generalized data queue is designed to primarily deal 
with the movement of data strings between processors. 
The queue provides independent 
operation 
for each of 


the two involved processors, 
which may operate upon 


the data contained within the queue independently. 
The 


queue handlers, however, must interact since the queue 
pointers must never be allowed to pass each other or in- 
valid data would be handled. This implies that mutual 
exclusion must be applied to the pointers to quarantee 
their integrity. 
If this is done, the queue can readily be 


applied to the special cases where string data transfers 
must take place between various processor boards. 


Multiprocessor 
systems infer that the application breaks 
down into functionally 
independent 
blocks or "tasks". 
Frequently, 
these global tasks will most often be further 


subdivided into smaller on-board 
or local tasks. These 
systems will frequently use real-time executive operating 
systems. 


Communications 
between tasks can involve the trans- 


fer of many types of information. 
In some cases, data 


strings must be moved. In others, the transfer 
may be 


only 
used 
for 
synchronization 
of 
events. 
Intel's 
RMX/SO 
multitasking 
operating 
system supports 
the 


movement 
of data (messages) through 
the use of ex- 


changes. 
In this implementation, 
actual messages are 


not moved in memory, but instead, a pointer is gener- 
ated to the message area and this variable 
is passed 


between tasks. Before proceeding with the development 
of a multiprocessor 
message driver, some time must be 


taken to assure that the messagel exchange relationships 
are fully understood 
by the reader. 


Messages 


A message is a collection of data that one task sends to 
another task. It may be thought of in the context of a 
letter which is to be sent from one person 
(task) to 


another. 
Like a letter, the purpose of the message is to 


convey information 
or to request a service. Messages 


used in RMX/SO 
systems conform to a standard 
format 


similar to conventional letter connotations. 
It contains a 


heading and a variable length data area. The heading 
can be from 5 to 9 bytes in length and corresponds to the 
format shown in Figure 7. 


The LINK PORTION 
of the heading is used by the 


RMX/SO 
nucleus to keep track of other messages which 


are addressed to the same place (exchanges). If no other 
messages are present, the field will be set to zero. 
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Exchanges 


The exchange can be thought of as a mailbox into which 
messages are placed. In reality, only the location pointer 
of the message is placed into the exchange. 
Each ex- 


change is defined by an Exchange Descriptor 
area of 


RAM memory. The format of an Exchange Descriptor 
is shown in Figure S. The purposes of each field will be 
defined 
in the following 
paragraphs 
and 
should 
be 


understood 
since the development 
of a multiprocessor 


RMX/SO 
exchange 
protocol 
will use many 
of these 


fields. 


MESSAGE 
HEAD 


MESSAGE 
TAIL 


TASK 
HEAD 


TASK TAIL 


EXCHANGE 
LINK 


MESSAGE HEAD is used to provide a pointer to the 
first message which has been placed into the exchange. 
If no messages are present at an exchange, the value of 
the field will be set to zero. As will be seen, this field can 
be tested by a task to determine if a message is already 


waiting at an exchange when the task is to accept a 
message. 


MESSAGE TAIL provides a pointer to the last message 
waiting at an exchange. If no messages are waiting, the 
pointer will be set to the address of the exchange. The 
multiprocessor 
interface 
which will be designed must 


provide an update capability for maintaining 
this field. 


TASK HEAD is a pointer to the first task which is wait- 
ing at the exchange for a message. If no task is waiting, 
this field will be set to zero. Again, a simple test, when 
sending a message to see if a task is to be activated, is to 
test the field for a zero value. 


TASK TAIL provides another 
pointer which indicates 
the last task which is waiting at an exchange. As with the 
Message Tail, the field is set to the address of the ex- 
change when no task is waiting at the exchange. 


EXCHANGE 
LINK contains 
the address of the next 


Exchange 
Descriptor 
in the list of all the exchange 


descriptors 
in the system. This value is established 
by 


the RMX/SO 
nucleus and does not require special atten- 


tion in the multiprocessor 
modifications. 


This section of the application 
note will deal with the 


generation 
of an RMX/SO 
extension which will allow 
the transfer of messages between tasks which reside on 
different processors. 
Three RMX/SO 
operations will be 


supported and parallel procedures developed. These will 
be the nucleus 
functions 
RQWAIT, 
RQSEND, 
and 


RQACPT. 


RQW AIT is used to allow a task to receive a message 
from an exchange. If a message is available, its location 
will be transferred 
to the receiving task and program 


execution will continue. 
When no message is available, 
the task will be placed on the wait list until such time 
that a message has been placed into the exchange by 
some other task. RQWAIT provides for the capability 
of allowing a maximum time during which a task will 
wait at an exchange for a message. The multiprocessor 
equivalent 
of this function 
which is explained in this 
application 
note is identified 
as IPW AlT. 
It is func- 


tionally equivalent 
except that no provision 
has been 


made to support a maximum time interval. 


RQSEND is a procedure 
which allows a task to send a 


message to an exchange. If no tasks are waiting at the 
exchange, 
the message will be queued with any other 


messages which may already be waiting there. If a task 
is found to be waiting at the exchange, it will be placed 
onto the ready list so that it can compete again for proc- 
essor resources. The multiprocessor 
equivalent defined 


by this note is called IPSEND. 


RQACPT 
provides a procedure 
which gives a task the 


ability to test an exchange to see if a message is present. 
If one is waiting, its address will be returned to the call- 
ing task. If no message is available, a value of zero is 


returned. 
The 
multiprocessor 
equivalent 
is 
called 


IPACPT. 


The concepts used to develop each of the three exten- 
sions are discussed in the following 
paragraphs. 
Not 


only should this development assist the user in creating a 
multiprocessor 
executive, but it should also help in the 


understanding 
of the operation of the RMX/SO 
nucleus. 


Multiprocessor 
Message 
Transfers 


Normal 
message 
transfers 
take 
place between 
tasks 


which are resident on the same processor board and thus 
are able to share a common memory area for the storage 
of the message's data. When a multiprocessor 
configur- 


ation is implemented, 
these tasks may not necessarily 


have all memory areas accessible to each other. An area 
of memory which is common 
to all processor 
boards 


must be created to implement a multiprocessor 
system. 


This memory will be hereafter referenced as GLOBAL 
memory. All common resources which may be needed 
or used by a task which might have a need to perform 
multiprocessor 
operations 
must use the Global memory 


area. 


The implementation 
of a RMX/SO 
extension which pro- 
vides a multiprocessor 
communications 
driver can be 


performed using the knowledge gained from the defini- 
tions of the fields in the messages and exchanges. The 
development 
will begin with the concepts 
involved in 


executing an exchange wait. 


First consider the condition in which a message is wait- 
ing at the specified exchange when the task performs a 
request to obtain a message from an exchange. In this 
case, the message can be accepted 
directly 
(and the 


pointer 
fields updated 
accordingly) 
and the task can 


proceed normally. The sequence of events for this type 
of condition can be seen in the flow chart of Figure 9. A 
complete listing of the code can be found in Appendix 
A. References will be made to lines of code which are 
pertinent to the discussion by using a pointer in paren- 
thesis. Thus a reference to code at line (1.14) will indi- 
cate program 
I, line 14 in the appendix. 


The procedure can examine the LINK field of the mes- 
sage to determine if more than one message is waiting at 
the exchange (1.36). A zero in the field indicates that no 
other messages are present. The value of the LINK field 
should be moved into the MESSAGE 
HEAD field of 


the Exchange Descriptor (1.36). The MESSAGE TAIL 
field should reflect the last message. If more messages 
are present, the field can be left unchanged; 
otherwise, 


the field should be set to the exchange address. The ad- 
dress of the message is returned to the calling program, 
allowing it to use the data contained 
in the message 


(1.40). Note how the use of a software semaphore has 
been used to prevent more than one processor modify- 
ing the exchange and message descriptor 
data at the 


same time (1.24; 1.39). 


The technique 
described 
above provides 
a direct ap- 


proach to getting a message from an exchange. A more 
complete methodology is required when a message is not 
waiting at the exchange. This is the subject of the fol- 
lowing paragraphs. 


As tasks queue up at an exchange waiting for a message, 
provision must be made to create and maintain 
a link 


list of those tasks. Since the source code associated with 
RMX/SO 
is not normally available to the user, the effect 


of using the existing data structures 
cannot always be 


determined. 
An extension must be developed which will 
support the maintenance 
of a link list of queued tasks. 


Thus, each task descriptor will have a THREAD pointer 
added which will point to the next task waiting at the ex- 
change. Each exchange descriptor 
will have two fields 


added, one for use as a TASK HEAD pointing to the 
first task waiting at the exchange, and a second field, 
TASK TAIL which points to the last task waiting at the 
exchange. 
These fields will be added 
to the existing 


RMX/SO 
descriptors 
for those tasks and descriptors 


which are associated with multiprocessor 
operations. 


Figure 10 provides representations 
of the exchange and 


task descriptors as they would be configured for various 
conditions. 
Consider 
first the condition 
in which one 


task is already waiting at an exchange. The TASK TAIL 
and the TASK HEAD will be pointing to the task de- 
scriptor of the waiting task. Since only one task is wait- 
ing, the THREAD 
field of the task will contain a zero 


value. Appendix A contains the listing of the code re- 
quired to add a task to the exchange queue. The pro- 
gram is the same as the one previously discussed when a 
message was waiting at the exchange as the calling task 
attempted to obtain a message. If the test indicates that 
no message is present (1.25), the fields must be updated 
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as shown in Figure 8 and add the new task to the waiting 
list. The RMX/80 
nucleus maintains the address of the 


task descriptor 
of the task currently running in a vari- 


able, RQACTV. 
This pointer to the current task must 
be placed into both the TASK TAIL of the exchange de- 
scriptor and into the THREAD 
of the last task queued 


onto the exchange (1.29). In addition, the THREAD 
of 


the current task should be set to zero to indicate that it 
will be the last task waiting at the exchange (I. 30). 


The reader, 
studying the program 
listings, might note 


the condition 
of the exchange having no tasks waiting 


when the task is queued up (1.28; 1.29). In this case, the 
TASK TAIL pointer is clearly pointing to the exchange 
descriptor 
and not to a task! 
The pointer 
normally 


placed into the task descriptor's 
THREAD 
field will be 
placed 
into a field of the exchange, descriptor. 
This 
potential 
trouble area is overcome by constructing 
the 


fields of both descriptors 
to have offsets equivalent as 
shown in Figure 10. The THREAD 
data will now be 


placed into the TASK HEAD field as should be done if 
no tasks are already queued up. 


Finally, 
since the task should no longer compete 
for 


system resources until a message is available to it, the 
program should be placed onto the delay list. However, 
since this list is maintained 
by RMX primative proce- 


dures which are unavailable to the user, the same effect 
can be obtained 
by constructing 
a multiprocessor 
user 


wait list and then suspending 
the task (1.32). At this 


point, 
the nucleus will activate another 
task from the 


ready list and the suspended 
task will remain in that 


state until it is resumed. When resumed, program execu- 
tion 
will begin at (1.35), where a pointer 
from 
the 


DELAY pointer of the task descriptor will be returned 
to the calling program. Programs which will activate the 
task must ascertain that the pointer contains a reference 
to the message which is to be received by the task. 


The conditions 
which may be encountered 
in perform- 


ing a sending of a message to an exchange must now be 
considered. 
Two paths must be explored in the discus- 


sion; the operations 
required when a task is waiting at 


the exchange and the operations used when a task is not 
already waiting. The program 
which is constructed 
to 


support 
the required 
operation 
is called IPSEND 
and 


will have its line numbers referenced as (2.n) where n is 
the line number on the listing. 


If the exchange to which a message is being sent does 
not have a task waiting (2.26), it is only necessary to 
modify the descriptors 
to indicate the presence of the 


message. Figure 11 shows the field pointer requirements 
for the various conditions which may be encountered at 
the exchange when no task is waiting. 


An exchange having no messages already present will 
have the MESSAGE 
TAIL 
pointing 
to the exchange 


descriptor. 
A message structure 
of the last message at 


the exchange will be defined based upon the MESSAGE 


TAIL and the first element of the structure will be set to 
point to the new message (2.28; 2.29). When no message 
was already queued, this action will set the MESSAGE 
HEAD to the new message. When a message was pres- 
ent, the LINK field will be set to point to the new mes- 
sages. Next. The LINK field'of the new message will be 
set to zero, indicating that it is the last message in the 
queue (2.30). Operation 
of the program 
can then con- 


tinue. 
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The operations 
become 
more complex 
when one or 


more tasks are already waiting at an exchange for a mes- 
sage. In this case, the task will have been suspended as 
was shown in the previous discussion about waiting for 
a message. A technique 
must be established 
to again 


cause the waiting task to be placed on the ready list of 
the RMX/80 
nucleus. 


Conceptually, 
this can be done by generating an inter- 


rupt which will cause all processors to test if they are the 
one which controls the task which is waiting at the ex- 
change to which the message has been sent. If not, no 
action will be taken by that board. If the task resides on 
the single board computer responding 
to the interrupt, 


the suspended task can be resumed and placed again on 
the ready list. For the purposes of this application note, 
interrupt 
level 4 will be used to provide the mechanism 


to cause each system processor to determine if the task 
to which the message is directed resides on that board. 


The generation of an interrupt onto the Multibus system 
bus is implemented 
on newer iSBC boards by merely 


adding jumpers to wire wrap posts on the board. Figure 
12 shows the schematic 
of the interrupt 
mechanism 
associated 
with interrupt 
level 4 on the iSBC 80/30 


single. board computer. 
An interrupt 
can be generated 


onto the Multibus system by toggling bit 7 of the I/O 


port. Note that the interrupt 
is also routed back to the 


source board, so all processor boards, including the one 
generating the interrupt, 
will respond to it. 


A program has been written and is shown in Appendix 
A which 
generates 
the 
required 
interrupt 
onto 
the 


system bus. 
The program 
is identified 
by the name 


SET$INT and is referenced in this application note with 
the pointer scheme (3.n) where n is the line number of 
the code. 


Of specific interest in the program 
listing is the use of 


software 
semaphores 
to provide 
an indication 
of the 


length of time which the interrupt 
line must be kept 


active. Semaphore 6 is used to provide mutual exclusion 
to the interrupt 
gneration 
mechanism (3.11) and sema- 


phore 5 provides the synchronization 
mechanism. 
The 


IPSTASKSHEAD 


IPSTASKSTAIL 


latter semaphore 
is set prior to establishing 
an active 


condition 
on the interrupt 
line (3.13). When the pro- 


cessor having the task which is to be activated recog- 
nizes the interrupt, 
it will clear the semaphore level. The 


interrupt 
should be held active (low) by the processor 


board which generates the interrupt until the semaphore 
has been cleared (3.16; 3.17). 


Note that in line (3.14), a processor identification 
num- 


ber was stored in the variable PROC$ID. 
The technique 


which can be used to obtain this target processor refer- 
ence is to store the processor number into the exchange 
descriptor STATUS field when the task is queued onto 
the exchange descriptor 
(1.27). When the message is 


finally sent to the exchange and the task is taken off the 
exchange 
descriptor 
(2.40), the identification 
can be 


stored for use by the interrupted 
processor. Any proces- 


sor which receives an interrupt with an identification 
in 


PROC$ID 
which does not match 
its own processor 


identification 
should ignore the interrupt. 


Figure 13 shows the process of dequeueing a task from 
the exchange descriptor. 
Since one or more tasks were 


waiting at tbe exchange, no messages could exist at the 
exchange. The first operation 
(2.36) involves adjusting 


the pointer to the first task waiting at the exchange to 
point to the next waiting task (if only one task was 
waiting, the value of zero will be stored as a pointer). If 
only one task is waiting (2.36), the exchange task tail is 
set to point to the exchange (2.37). The message link and 
the task delay pointers must be set to the address of the 
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message (2.3S) to support 
standard 
RMX/SO protocol. 


The task delay pointer is used by the receiving task to 
pass the address of the message when it returns to the 
active condition 
(1.33). 


Before generating 
the interrupt 
which will place the 


waiting task onto the ready list, parameters 
which iden- 
tify the task's processor (2.3S) and internal descriptors 
(2.39) must be placed into a global memory area. As will 
be seen, this area can then be tested by each processor 
when an interrupt 
is received. An interrupt can now be 
generated which will cause all processors to examine the 
multiprocessor 
global memory to determine if the mes- 
sage is directed to a task which resides on that processor 
board. 


As the interrupt 
is generated, each processor in the sys- 
tem will service the request. An RMX/SO task can be 
written which waits at the interrupt exchange and which 
will service the interrupt 
request. However, in order to 
optimize 
the 
system 
performance, 
a user 
interrupt 


routine has been provided. 
A listing of this program, 


INT4, can be found in Appendix A. Code line numbers 
for this listing are identified by the nomenclature 
(5.n) 


where n is the line number of the code. 


The program will first test the target processor identifi- 
cation (5.40) to determine if the task to be placed ooto 
the ready list resides on the board. 
If the interrupt 
is 


found to be for another master, it will be ignored and 
the interrupted 
program will continue (5.41). 


If, however, the processor is the recipient of the mes- 
sage, the global 
field containing 
the identification 
is 
cleared 
(5.43), 
the interrupt 
is acknowledged 
(5.44) 
allowing the sending master to continue the execution of 
its tasks, and a message is sent to the RMX/SO interrupt 
handler task, INTHND 
(5.45). 


The interrupt handler continues with the INTHND pro- 
cedure which is identified by the use of (6.n) where n is 
the line number of the code in the procedure. 
This task 
operates 
under the standard 
RMX/SO nucleus and is 
waiting at an interrupt 
exchange (6.34) for an interrupt 


message to be sent by the interrupt 
handler program, 


INT4. A second validity test is then performed (6.36) to 
verify that a multiprocessor 
message has actually actu- 


ated the task and that the interrupt is not to a spurious 
noise signal. The task pointer is saved and then cleared 
to allow transfer 
of additional 
messages (6.3S; 6.39). 


The task which was waiting at the exchange is then again 
placed onto the ready list by performing 
a "resume" 
RMX/80 command (6.42). Thus, the transfer of a mes- 
sage between two tasks residing on either different 
or 
the same processors has been completed. 


Many times it is required 
to test an exchange for the 
presence of a message without 
actually waiting if no 


message is available at the time. This is the function of 
the standard 
RMX/SO procedure 
RQACPT. 
A multi- 
processing version of this function, 
IPACPT, 
was in- 
cluded in the extension to the RMX/SO nucleus. 
It is 


found in Appendix A and is identified by the references 
(4.n). 


Basically, the program need only determine if a message 
is present at the exchange. This is done by testing the ex- 
change message head field (4.25) for a non-zero value. 
If no message is present, the value will be set to zero and 
a return to the calling task can be performed which indi- 
cates that no message was found (4.2S). If a message is' 
found, 
the functions 
defined in IPWAIT 
can be exe- 
cuted to adjust the descriptor fields and return the mes- 
sage address. This is most easily accomplished by simply 
calling the IPW AIT procedure 
(4.32). 


Before the multiprocessor 
message exchange procedures 


just described can function properly, various data fields 
must 
be initialized 
just 
as is done 
by the RMX/SO 


nucleus. Two programs have been written to accomplish 
this task. 
One, the GLINIT 
program, 
initializes 
the 


common global variable fields which are common to all 
processors. 
This includes such fields as the processor 


identification 
(7.14) and the target task pointer 
(7.9). 


This program also initializes the extensions which have 
been made to the exchange descriptors 
(7.10). 


A second program 
operates 
on functions 
which are 


unique to each processor board in the system. For exam- 
ple, the I/O ports used to generate the global interrupts 
must be initialized to the correct state (9.43). The inter- 
rupt exchange (9.45) and interrupt 
handler (9.46) must 


be created and linked to the nucleus. Since user written 
interrupt 
service routines are used, they must also be 


defined to properly vector the interrupts 
when they oc- 


cur. This is the function of lines (9.47) and (9.48). 


If a board other than the iSBC SO/30 computer 
were 


used in the system, 
this second initialization 
routine 


would require modification 
to adjust it to the peculiar 
characteristics 
of the board used. 


All of the tasks which provide for multiprocessor 
mes- 


sage transfers 
rely' upon the ability of procedures 
to 


exclude access to the RMX/SO extension which provides 
this capability until the message has been transferred 
or 


queued 
onto 
an exchange. 
This is done using sema- 
phores 
in 
two 
programs 
identified 
as 
LOCK 
and 


UNLOCK. 
The same techniques 
which were earlier 


described are used and can be seen in the Appendix list- 
ings. Since the processors used in this application 
note 


were iSBC SO/30 single board computers, 
a bus lock 


command 
(S.17) for that board was used. The use of 


other boards, 
would require a modification 
of this in- 
struction to conform to the board design. The bus lock 
command 
has no effect on memory which is accessed 


using the on-board 
local bus. In order to provide an 


effective 
semaphore, 
the RAM used for a software 


semaphore must reside in a memory area which is exter- 
nal to the processor 
board. 
For this reason, 
the dual 


ported memory of an iSBC 80/30 board cannot be used 
and memory which is not contained 
on a board which 
uses the semaphore must be included in the system. 


System 
Resource Sharing 


Many of the advantages of a multiprocessor 
system can 


be lost when drivers and peripheral 
devices are dupli- 


cated for each single board 
computer. 
For example, 


consider a system which maintains 
an on-going inven- 
tory system on a mass storage device such as a disk 
drive. If distributed 
single board computers are used to 


support 
each individual 
operation 
of a product 
as it 
moves through the process, only a common disk system 
will allow modification 
of the data base by each proces- 


sor. If a means can be found to also share the driver to 
the disk, considerable 
programming 
effort 
and code 


space can be saved. 


The RMX/80 nucleus is designed to support many spe- 
cial 110 device handlers such as the terminal handler, 
and the disk file system (DFS). An intermediate level in- 
terface can be constructed 
which will allow any of the 


system processors to use common drivers on one master 
board. The program which will be developed in this ap- 
plication 
note 
for 
interfacing 
with common 
system 
drivers is called BIP!. A listing of this program can be 
found in Appendix B. 


Several 
options 
exist when selecting a target 
device 


which is to contain 
all the required system resources. 


One possibility is to arbitrarily 
pick a processor board 
and configure the necessary drivers onto it. However, 
another choice seems to present many more system ben- 
efits. This is the dedication 
of one processor board to 
the operator 
interface 
and then using the iSBC 802 
RMX/80 
BASIC interpreter 
on this board. 
Consider, 


for a minute, the implications of configuring a system in 
this manner. 


It is a fact that minimal development 
cost will be in- 


curred 
if the programming 
is done 
in a high level 
language. 
Unfortunately, 
systems 
involving 
large 
amounts of digital input and output, or having to inter- 
face with peripheral controllers, 
do not lend themselves 


well for programming 
with a high level language. On the 
other hand, it is difficult to perform data manipulations 
of strings and numerical data using programs written in 
lower level languages. An optimum solution is then to 
create a system which combines the attributes of both of 
the language types. 


An analogy can be drawn between a conventional 
single 
processor system and one which uses multiprocessors. 
In the system which uses a single processor, 
assembly 
language routines can be written for minimum code size 
or time critical functions and can be linked with PL/M 
or FORTRAN 
programs 
to produce 
the final object 


module. A multiprocessor 
system can be thought 
of in 


the same manner. 
Here, individual functions are repre- 
sented by a complete single board computer, 
each of 


which can use some combination 
of the available lan- 
guages. System design can emphasize the positive attri- 
butes of each language which is available. 


The iSBC 802 BASIC package 
can be included 
in a 


multiprocessor 
system much the same as a common sub- 
routine 
in smaller 
systems. 
Various 
other 
processor 


boards can use the 110 capabilities of the BASIC inter- 
preter as needed. In particular, 
the DFS (Disk File Sys- 
tem) and terminal handler can be shared as needed by 
each board. 


Because the 110 drivers contained in the BASIC Inter- 
preter use standard RMX/80 exchanges, they cannot be 
directly 
accessed 
using 
the 
multiprocessor 
interface 


which has been developed 
earlier 
in this application 


note. A special intermediate 
interface is required which 
will interface 
with the iSBC 802 software. 
This is the 


function 
of the program, 
BIPI, 
which will be linked 


together 
with the other tasks contained 
on the single 


board computer 
used for the BASIC interpreter. 
Cer- 
tainly, the concepts which will be used to develop the in- 
terface to the common 
110 services of the iSBC 802 
software can easily be extended to support other pack- 
ages such as the iSBC 801 FORTRAN 
run-time pack- 


age. 


Requests 
to have a service performed 
by the 
BIPI 


module will be received in the form of a message to the 
global exchange, 
BIPI$EX. 
A definition 
of services 


which may be required by a remote processor will pro- 
vide the basis for a definition 
of message types which 


will be supported 
by the interface. 


A fundamental 
request 
will be to gain access to the 


operator 
keyboard 
or 
display 
terminal. 
Thus 
two 


message types can be defined to read from the terminal 
keyboard (READ$TYPE) 
and to output to the display 


(WRITE$TYPE). 
To provide 
process 
tasks with the 


ability to examine and modify data which is stored on 
the disk drive media, a set of commands 
must also be 


generated which interface to DFS. Five command types 
will prove to be sufficient for this task. Corresponding 
to the RMX DFS disk message types, the program will 
define 
disk open 
operations 
(DFS$OPN) 
and 
close 


operations (DFS$CLS). Positioning capabilities are sup- 
ported by a seek command (DFS$SK). Finally, read and 
write requests are supported by the read &DFS$RD) and 
write (DFS$WT) commands. 


Examination 
of the program 
listing will indicate that 


disk request message types use the type numbers from 
72 to 79. This provides a simple method of distinguish- 
ing a disk request from a terminal operation 
message. 


The numbers were chosen such that subtraction 
of 64 


from the message type will yield the message type which 
must actually be sent to the DFS exchanges by BIP!. 


In many 
cases, 
it may be desirable 
to suspend 
the 


BASIC program 
(or the FORTRAN 
program) 
while 


peripheral 
I/O resources are being shared by another 
processor. 
An example might be when a task is report- 
ing an alarm 
condition 
to the operator 
and requires 
some interactive communications 
with him. Certainly, 
these communications 
cannot be intermixed with mes- 
sages from the program which was running on the ter- 
minal. Therefore, 
two additional 
commands have been 
provided 
which will suspend 
(SUSBAS) and resume 
(RES BAS) the task which might have been competing 
for a system resource. 


Study of the program 
listing for BIPI will provide the 


reader with an insight into the use of the multiproces- 
sing RMX/80 extensions which have been developed in 
this application 
note. Both standard 
RQ ... 
calls and 
multiprocessor 
IP ... 
calls are integrated into the task. 
When the concepts are clear, a real application example 
can be examined to see how multiprocessing can assist in 
the solution of an otherwise very complex design prob- 
lem. 


The previous 
development 
of multiprocessing 
exten- 


sions to the RMX/80 nucleus allows the application ex- 
ample development to continue. A solution using multi- 
processor 
techniques 
can be easily implemented 
using 
these concepts 
and the extensive line of Intel single 
board computer products. 
The results can be examined 


to verify that 
multiprocessing 
has provided 
a better 


solution than would have been gained if only one proc- 
essor had been used. 


The merits and deficiencies of multiprocessing 
must be 


examined to ascertain that the application 
is likely to 
benefit from a solution which uses more than one proc- 
essor. 
Certainly, 
many 
functions 
can be better 
per- 
formed using a higher speed microcomputer 
on a single 


board. 
The decision 
to use multiprocessing 
must be 


made on a cost/performance 
basis. 


The application defined at the beginning of this applica- 
tion note provides an excellent example of the multi- 
master solution. Each functional section of the applica- 
tion is developed into an actual board implementation 
which includes all resources required for its support. 


Supervisor 
Implementation 


The supervisory functions are likely to require extensive 
computational 
functions, 
report generation 
and oper- 
ator interaction. 
It is also likely that, as the management 


gains experience with the system, the functions required 
and the algorithms 
used will be constantly 
modified. 


These operations 
are not generally real-time driven so 


extremely high system throughputs 
will not be required. 
The Intel iSBC 802 BASIC package running on a single 
board computer will provide a solution to these require- 
ments. 
In terms of hardware 
design, the supervisory 


functions can be considered without regard to any con- 
trol functions. 
The primary 
interface 
can be through 


data bases stored on a mass storage device and with the 
"peek" 
and "poke" 
instructions 
where necessary. The 


system configuration 
for the supervisory 
function 
can 


be seen in Figure 14. 


Because the supervisor 
will rely extensively upon the 


interaction 
with 
the operator 
and 
the mass storage 


devices, it is natural that it have associated with it the 
terminal handler and the DFS system. The addition of 
the BIPI interface task to the BASIC interpreter 
pack- 


age will allow the control tasks to easily interface to the 
inventory and control data bases as required. Figure 15 
shows the primary tasks which operate on the supervisor 
control processor. 
Note that there exists two operating 


tasks, BASIC and BIPI, along with support 
functions 


of the DFS and terminal handler. Any program which is 
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being run under BASIC will essentially become an ex- 
tension of the existing interpreter task. 


Programs can be written which will provide the required 
algorithms to implement the inventory control system 
and production 
scheduling of the system using a high 


level language which may easily be modified as required 
by the future system requirements. 


The rest of the system consists of control elements. They 
may easily be thought 
of as supervisor 
subroutines 
which are called as required and which have parameters 
passed with the call. Unlike conventional designs, these 
subroutines will reside on different processor boards. 


One functional task has been defined as weighing the in- 
gredients according to a formula:in order to provide the 
correct ratio of ingredients to produce the final product. 
As with most functional 
areas, a closer examination 
shows that this involves rather complex relationships 
and breaks down into many smaller tasks. Figure 16 
shows the logical flow of operations which are required 
to weigh the ingredients into their proper ratios. From 
the information 
contained in this flow diagram, tasks 
and exchanges necessary to implement the function can 
be defined and the coding generated. 
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The tasks which were defined for this application exam- 
ple are shown in Figure 17. The task communication 
paths through exchanges has also been illustrated in the 
figure. Basically, the weighing function consists of four 
on-board tasks and calls upon tasks contained on other 
boards as is required using the global exchanges created 
according to the structure defined earlier in this applica- 
tion note. Some time should be taken to explain the 
functions of each task and how they relate with tasks of 
other processors in the multiprocessor 
design solution. 


The schedule task, SCHDLE, is the interface between 
the operator 
commands 
and the weighing functions. 
This task will wait for a POKE command to pass it a 
flag which indicates that a batch is to begin. At this 
point it will organize the data which will be required by 
the weighing task into predefined 
memory structures 


and will then signal the weighing task to begin its opera- 
tions. A second function performed by the schedule task 
is the initialization of system variables each time a reset 
is performed on the processor board. 


The weighing task, SCALEO, is responsible for actually 
producing the required amounts of each ingredient. All 
the functions indicated in Figure 15 are implemented by 
the weighing task. The task uses resources of other proc- 
essors as well as on-board tasks to assist in the prepara- 
tion of a batch of material. 


A scale driver task, SCLWT, is included on the proces- 
sor as a local support task to assist the weighing opera- 
tions. It is responsible for interfacing with the analog to 
digital converter 
(ADC) and converting the data re- 


SCALE 
DRIVER 
SCLWT 


ceived from it into engineering units which represent the 
actual weight of material which is in the scale. The scale 
weights are passed between two tasks using an exchange 
(SCLWTEX) to provide mutual exclusion'. 


In wighing applications, 
many times a feeder will mal- 


function 
and not deliver material 
into a scale when 


directed to do so. If no provision is incorporated into a 
system design to detect this condition, 
an infinite time 


period could be requiTed to weigh a material and, need- 
less to say, the system throughput 
would be severely 


degraded. A slow fill detection algorithm is normally in- 
corporated 
into weighing systems to provide this ser- 
vice. For this application, 
this function 
is generated 


using a slow fill task, SLOFIL. Functionally, the opera- 
tion of the task is to accept a message from the weighing 
task 
that 
it has 
commenced 
weighing 
a material. 


SLOFIL will then begin a timed wait at an exchange for 
a period which corresponds with the maximum allow- 
able time period for the material to be added into the 
scale. If the time elapses and a message has not been 
received from the weighing task indicating that cutoff 
has been reached, a message will be sent to the weigher 
indicating that a problem with the equipment exists. The 
operator can then be alerted to correct the malfunction. 


The weighing function provides a good example of how 
off-board 
system tasks can be used to interface with 


those which are on-board to extend the capabilities of 
the system. The sharing of the terminal handler and of 
the DFS system has already been discussed. The weigh- 
ing function calls upon these tasks, through BIPI, for 
assistance 
in updating 
the inventory 
and when it is 


necessary to communicate with the operator to resolve a 
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system problem. Other examples can also be seen. For 
example, the decision was made to use a common digital 
I/O board for all process functions. This gives the abil- 
ity for access to the control and sensor devices to both 
the controlling tasks and to the operator for performing 
maintenance programs or even operating the system in a 
semi-automatic 
mode should a controller fail. All I/O 


data is moved through exchanges, PTBnEX, and the ac- 
tual I/O is performed by a task which resides on another 
board. 


Another example of multiprocessor communications in- 
volves message passing between the weighing tasks and 
the mixing tasks contained 
on another 
board. 
The 


weighing task is responsible for discharging the material 
into the mixer, but it certainly cannot do so unless it 
ascertains that the mixer is empty and available. It does 
this by testing the exchange, MIXINT, for the presence 
of a message indicating that the mixer is available. The 
mixer tasks, as will be seen, support this exchange by 
removing 
the message when no material 
should 
be 


added into the mixer and placing a message into the ex- 
change when a mixer is ready. Further communications 
with the mixer are required because the mixer task must 
be synchronized with the discharging of material into it 
by the weighing function. This is provided by message 
transfer through global exchange, MIXEX. 


Finally, because only a limited amount of RAM is avail- 
able in a particular system, the free space manager was 
used in this application 
to allocate blocks of global 


memory to individual processor boards. This allocation 
is handled by sending messages to the global exchange, 
BUSEX, which will be received by an intermediate task 
on another processor and will result in a block of mem- 
ory being allocated to the weighing task for message 
generation. 


Other Application 
Tasks 


A processor was dedicated to support each of the re- 
maining three application processes. It would be repeti- 
tious to again detail each subtask which makes up each 
functional 
area. 
The 
same 
techniques 
which 
were 


demonstrated 
in defining the weighing application can 


be used to define the generalized functions and to break 
these functions into codable tasks. 


Data is transferred 
between processors in the form of 


messages which occupy RAM area. The use of the 
RMX/80 Free Space Manager provides a global tool to 
allocate and reclaim this memory area. The Free Space 
Manager was implemented on the mixing processor be- 
cause substantial amounts of ROM remained on-board 
after coding all the required tasks. This ability to select 
from many processors the location for global resources 
is an important tool in multiprocessor applications. 


Total Application 
Configuration 


Figure 18 shows the functional software implementation 
for the entire chemical application chosen for this appli- 


cation note. The approach has demonstrated that a rela- 
tively complex application can easily and quickly have a 
control solution generated using multiprocessing 
con- 


cepts. The ability to extend the multitasking capabilities 
of the RMX/80 
nucleus led toward 
the creation 
of 


modular software. 


In addition to allowing the generation of modular soft- 
ware, the approach taken on this example has allowed a 
modular 
approach 
to the hardware 
implementation. 


Figure 19 provides the complete hardware block dia- 
gram of the final implemented system. Each functional 
section was designed as though it were the only required 
element to create a solution to the control problem. 
Indeed, even after start-up, a functional module can be 
removed from the system without affecting the opera- 
tion of remaining 
modules. 
The concept can be ex- 


tended to include the capability of adding new processes 
to the total system without having to disrupt the existing 
production 
flow control. 


v. CONCLUSION 


This application note has de~onstrated 
how a user can 
extend the concepts of multitasking 
into a multiproces- 
sing/multitasking 
environment. The built-in multiproc- 


essing capabilities of the various Intel single board com- 
puters have been explained and their implementations 
demonstrated 
through examples. 


Resource 
sharing 
between 
processors 
has 
been dis- 
cussed. In particular, 
the use of a high level language 
such as BASIC or FORTRAN as a supervisor has been 
explained and shown in an application. Since these soft- 
ware packages contain the resources required for disk 
support and terminal I/O, 
a program has been devel- 


oped which will allow other processors 
to share the 


RMX/80 drivers. 
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Finally, 
an application 
has been selected, 
and a control 


solution 
developed 
using the cqncepts 
derived 
in the ap- 


plication 
note. 
The 
operation 
of the 
RMX/80 
exten- 


sions have been tested 
and their 
operation 
verified. 


Multimaster 
operations 
are 
possible 
because 
of many 
built-in 
features 
of the Intel products 
and the extensions 
to the RMX/80 
nucleus 
used in this application. 
A sum- 


mary 
of these 
features 
an'd the corresponding 
product 


is: 


Disk File System 
- 


The 
RMX/80 
Disk 
File 
System 
CDFS) provides 
a 


common 
resource 
which 
allows 
tasks 
to access 
or to 


store 
data 
on a diskette. 


Interprocessor 
Communication 
Software 
- 


The software 
developed 
in this application 
note pro- 


vides 
an 
extension 
to the 
RMX/80 
nucleus 
which 


allows 
tasks 
to reside on any multimaster 
board 
con- 


nected 
to the Multibus 
system 
bus. 
Multitasking 
Capability 
- 


Furnished 
by the RMX/80 
nucleus. 
It allows the user 


to share 
the on-board 
resources 
of a processor 
board 


between 
multiple 
tasks 
or functions. 


Message 
Transfer 
Capabilities 
--:- 


Also 
furnished 
by the 
RMX/80 
nucleus. 
This 
func- 


tion 
allows 
data 
to be passed 
between 
tasks 
to pro- 


vide both 
an Information 
exchange 
and 
a means 
of 


task synchronization. 


Free Space 
Management 
- 


The RMX/80 
executive 
provides 
the ability 
to share 


memory 
between 
various 
tasks. 
Memory 
which is not 


constantly 
required 
can 
be used 
by more 
than 
one 


user, 
then 
returned 
to the memory 
pool. 


Terminal 
Handler 
-'--- 


The RMX/80 
terminal 
handler 
provides 
a convenient 


resource 
for supporting 
the communications 
with the 


operator 
via a CRT 
terminal. 


Bus Arbitration 
Logic - 


The Intel single board 
computers 
used in this applica- 


tion incorporate 
bus arbitration 
logic which 
controls 


the bus access 
to the Multibus 
system 
bus. 


Parallel 
Priority 
Logic - 


The application 
uses a parallel 
priority 
logic network 


which 
is constructed 
on a prototype 
board. 
In con- 


junction 
with the bus arbitration 
logic on each multi- 


master 
board, 
it.controls 
the requests 
for data 
trans- 


fers over the Multibus 
system 
blfS. 


Bus Lock 
- 


The 
capability 
of assuming 
exclusive 
control 
of the 


Multibus 
system 
bus 
by using 
the 
bus 
lock 
mecha- 


nism 
allows 
the 
implementation 
of software 
sema- 


phores. 
These 
semaphores 
are 
used 
to 
provide 


mutual 
exclusion 
of certain 
physical 
resources. 


BASIC Interpreter - 


The use of the iSBC 802 BASIC interpreter greatly 
reduces the amount of time required for the genera- 
tion of report 
programs 
and of interactive 
com- 


munications with the operator. 


PLiM 80 High Level Language - 


This softwasre language provides an efficient means 
of coding the application software where intensive bit 
manipulations are required. The structured language 
also provides a rapid development cycle. 


The reader should have considerable insight into possi- 
ble system level solutions to applications which he may 
face in his particular expertise. The increased productiv- 
ity which results from applying the engineering/pro- 
gramming 
resources into application 
oriented 
efforts 


can easily be seen. The development costs which can be 
saved by using modular software and high integration 
level board products 
can certainly justify the use of 


these system solutions. 


I would like to extend my gratitude to Steve Verleye for 
his valuable assistance in generating the multiprocessor 
communications programs used in this application note. 


APPENDIX A 
MULTIPROCESSOR MESSAGE TRANSFER PROGRAMS 


This 
procedure 
provides 
the 
inter-processor 
wait 
facility. 
If 
a 
message 
is 
available 
at 
the 
given 
exchange 
it 
is 
taken 
off 
the 
exchange 
and 
its 
address 
is 
returned 
to 
the 
calling 
routine. 
If 
no 
message 
is 
available, 
the 
processor 
ID 
is 
encoded 
in 
the 
status 
field. 
the 
task 
address 
is 
queued 
on 
the 
exchange 
list, 
and 
the 
task 
is 
suspended. 
When 
a 
nessage 
is 
sent 
to 
the 
exchange 
by 
another 
processor, 
the 
processor 
ID 
is 
used 
to 
send 
the 
task 
and 
message 
addresses 
into 
the 
incoming 
task 
queue 
for 
the 
processor 
and 
then 
interrupt 
it. 
The 
service 
routine 
thus 
activated 
sets 
the 
delay 
field 
of 
the 
indicated 
task 
equal 
to 
the 
me~sage 
addr~ss 
and 
RESUMEs 
the 
task. 
The 
task 
then 
simply 
RETUR~s 
the 
stored 
message 
address. 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


*/ 


$i nclude 
(:fl:g lobal. ext) 


/* Declaration 
of 
global 
inter-processor 
data 


structures 
*/ 


de cIa re 
proc$id 
byte 
external, 
J3y$pid 
byte 
external, 
inSque 
address 
external; 
declare 
my$proc$id 
literally 
'my$pid 
I, 
int$procSex 
ch 
literally 
in$que '; 


$include(:fl:sema.ext) 
lock: 
procedure 
(sema$id) 
external; 


declare 
sema$id 
byte; 
end; 


unlock: 
procedure 
(semaSid) 
external; 


declare 
sema$id 
byte; 


end; 
$include(suspnd.ext) 
RQSUSt': 
PROCEDURE 
(T$PTR) 
EhTERNAL; 


DECLARE: 
T$PTH 
ADDRESS; 


END 
HQSU SP; 


$include(msg.elt) 
DCCLARE 
J'1SG$HDR LITERALLY 
, 


LINK 
ADDRESS, 


LCNGTH 
ADDRESS. 


TYP E 
BYTE. 


HCME$EXCrlANGE 
ADDRESS, 


RESPONSE$E:XCrIANGE 
ADDHESS' 
; 


DECLARE 
;'1SG$DESCRIP'rOH 
LITERALLy 
'STRUC'rURE 
( 
MSG$HDR, 
R81Y\AINDER(1) 
BYTE) 
'; 


$include(:fl:iptask.elt) 
DEcLAHE 
IP$TASK$DESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 


DELAY$LINK$FORWARD 
ADDRESS, 
DELAY$LINK$BAr.K 
,ADDRESS, 
THR8AD 
,l\DDRESS. 


DELAY 
ADDRESS, 
EXCHANGE$ADDRESS 
ADDRESS, 


SP 
ADDRE S5. 


MARKER 
ADDRESS, 


PRIOHrrY 
BYTE, 
STA'fUS 
BYTE, 


NAME$PTR 
ADDRESS. 
TASK$LINK 
ADDRESS, 
IP$THHEAD 
ADDRESS) 
'; 
$include(:fl:ipexch.elt) 
DECLAHE 
IP$EXCHANGE$DESCRIPTOR 
LITERALLY 
.STRUC'fURE ( 
i'lSG$HEAD ADDRESS 
MSG$TAIL 
ADDRESS, 
TASK$HEAD 
ADDRESS, 
'l'ASK$'l'AILAOO RESS . 
NEXT$EXCB 
ADDRESS, 


RESERvED 
(10) 
BYTE, 
I~$TASK$HEAD 
ADDRESS, 
IP$TASK$TAIL 
ADDRESS) 
'; 


$include 
(common. elt) 


DECLARE 
TRUE 
LITERALLY 
"0FFH'; 
DECLARE 
FALSE 
LITERALLY 
'00H'; 


DECLI\RE 
BOO L8AN 
LITERALLY' 
B'l'fE.; 


DECLARE 
FOREVEH 
LI'fERALLY 
'I'1H 
ILE 
1'; 


Slist 


declar-e 
I,QAC'fV addr-ess 
exter-nal; 


23 
2 decla r-e 


(exch$adr-,delay,tenp$nsg$ptr-,last$task$ptr-) 
addr-ess, 


(temp$nsg 
based 
ternp$msg$ptr-) 
msg$descr-iptor-, 
(last$task 
based 
last$task$ptr-) 
ip$task$descr-iptor-, 


(exch 
based 
exch$adr) 
ip$exchanqe$descriptor-, 
(task 
based 
R~ACTV) 
ip$task$descr-iptor; 


24 
2 


25 
2 
26 
2 


27 
3 
28 
3 
29 
3 
30 
3 
31 
3 
32 
3 
33 
3 
34 
3 


35 
2 


if 
(temp$msg$ptr-: 
= 
exch. msg$head) 
=0 
then 


do; 
/* 
no 
message 
at 
exchange, 
queue 
task 
up 
*/ 


task.status=task.status 
OR 
shl(my$procSid,3); 


la st$task $ p tr=ex ch. ip $task $ ta il; 
1ast $ task. ipSt hread, exch. ip$task$ 
tai l=kQAC'fV; 


task.ip$thr-ead=O; 
call 
unlock(7); 
call 
RQSUSP(RQACTV); 
r-etur-n task. delay; 
end; 


/* 
'fhere 
is 
a 
message 
here. 
Dequeue 
it and 
return 


its 
address 
*/ 


if(exch.msg$~e~d:= 
temo$msg.link) 
=0 
then 


exch. msg$tai 
l=.e xch; 
temp$msg.link=temp$msg$ptr; 
call 
unlock(7); 
return 
teQp$msg$ptr; 
end; 


MODULE 
INFORMATION: 


CODE 
AREA 
SIZE 


VAlUABLE 
AREA 
SIZ 
E 


MAXIMUM 
STACK 
SIZE 
133 
LINC:S 
HEAD 


fj 
PROGRAM 
EI-mOR(S) 


00F6H 
00 DOH 


Okl0Arl 


241;D 
0D 
HiD 


$title('IPSE:ND 
routine. 
Version 
1.3') 
IPSt:ND: 
do; 


/* 
+++++++++++++++++++++++++++++++++++++~+++++++++++++++++++ 


'l'hisroutine 
provides 
the 
interprocessor 
send 
facility. 


If 
no 
tasks 
are 
waiting 
for 
the 
message. 
the 
message 
is 
queued 
on 
the 
exchange. 
If 
a 
task 
is 
waiting, 
it 
is 
taken 
off 
the 
queue, 
given 
the 
address 
of 
the 
message. 
and 
queued 
on 
the 
interprocessor 
exchange. 
Following 
this 
an 
interrupt 
is 
gener~ted 
to 


signal 
the 
responsible 
processor 
that 
~ 
task 
is 
ready. 


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


*/ 


$include(suspnd.ext) 
RQSUSP: 
PROCtmURE 
(T$P'l'R) 
EXTP,RNAL; 
DECLARE 
T$PTR 
ADDRESS; 


END 
RQSUSP; 


$includ~(msg.elt) 
DECLARE 
MSG$HDR 
LITERALLY 
LINK 
ADDRESS. 
LENGTH 
AOORESS, 
TYPE 
BYTE, 
aOIVlE$EXCHANGE 
ADDRESS. 


RESPONSE$EXCHANGE 
ADDRESS'; 


DECLl\RE 
:V\SG$DES~RIPTOR 
LITERl\LLY 
'STRUCTURE 
( 


MSG$HDR, 


HEMAIl~DF.:H (1) 
8Y'l'~)'; 
$include 
(:fl: 
iptask.elt) 
DECLAHE 
IP$TASK$DESCHI 
PTOR 
LITERALLY 
I STRUC'l' UHE 
( 


DELAY$LINK$FOHWAHD 
ADDRESS, 
DELAY$LINK$BACK 
ADDRESS, 
T HHEAD 
ADDRB S8 •. 


DELAY 
AODHESS, 
EXCdANGCSAODRESS 
ADDnESS, 


81' 
ADDRESS, 


MARKEl~ 
ADDRE:SS, 
PRIOHIT'i 
Byn~, 
STATUS 
8YTE, 
NAME$1'TR 
ADDRESS, 
Tl\.SK$LI 
NK 
ADDRE 55, 
IP$THHEAD 
ADD HESS) I; 
include(:fl:ipexch.elt) 
DECLAR E 
I p$ EXC llANG E$ DESCRIl:'TOR 
LI 'fCRALLY 
'5TRUCT 
UHE ( 


MSG$HEAD 
ADDRESS, 
J'1SG$TAIL 
ADDRE SS, 
TASK$HEAD 
ADDRESS, 
TASK$TAIL 
ADDRESS. 


NEXTSEXC,1 
ADDRESS. 


HESERVED 
(10) B'iTE, 
IP$TASK$8EAD 
ADDRESS, 
If'$TASK$TAIL 
ADDRESS) 
I; 
$include 
(comon.elt) 
DECLARE 
TRUE 
LITERALLY 
'OFFH'; 


DECLARE 
FALSE 
LITERALLY 
'UOH'; 


DECLARE 
BOOLEAN 
LITERALLY 
'R'iTE'; 


DECLAHE 
FOREVER 
LITERl\LLYI"HILE 
1'; 
Sli st 
$include 
(:f 1: sema. ext) 
lock: 
proter'lure 
(sema$ic'!) 
external; 


decla.re 
serla$id 
byte; 


end; 


unlock: 
procedure 
(sema$id) 
external; 


declare 
sema$id 
byte; 


end; 
$include(:fl:global.ext) 
/* Declaration 
of 
global 
inter-processor 


data 
structures 
*/ 


de cIa re 
proc$id 
byte 
external, 


my$pid 
byte 
exte rnal, 
in::>que address 
external; 
declare 
my$procSid 
literally 
'my$pid', 
int$procSexch 
literally 
'inSque'; 


set$int: 
procedure 
external; 
end 
setSint; 


de cIa re 
(exch$pti,msg$ptr,last$msg$ptr,task$ptr) 
address, 


26 
2 
27 
2 
28 
3 


29 
3 
30 
3 


31 
3 


32 
3 


33 
3 


34 
2 


35 
3 
36 
3 
37 
3 


(eX'ch'based 
exchSptr) 
ip$ex~hangeSdescr 
iptor. 


(ms'g [)aseo msgSptr) 
msgSdescriptor, 
(lastSmsg 
based 
lastSmsg$9tr) 
usgSdescriptor. 


(task 
based 
taskSptr) 
ipStaskSdescr 
iptor; 


if 
(taskSptr: 
= 
exch. ip$taskShea 
d) =0 
then 
do; 
/* 
no 
tasks 
waiting; 
queue 
messaqe 
*/ 


la stSmsgSo 
tr=ex ch. msg St ai 1; 
last$msg.link.exch.msgStail=msgS~tr; 
msg. li nk=O; 
call 
unlock 
(7); 
return; 
end; 


else 
do; 


/* 
unqueue 
task 
and 
send 
it 
to 
proper 
processor 
*/ 


if(exch.ipStaskShead:= 
task.ipSthread)= 
0 
then 


exch.ip$task$tail=exchSptr; 
msg.link,task.delay=msgSptr; 


procSid=shr(task.status.3) 
and 
07H; 


intSprocSexch=taSkSptr; 
task. ip$threao=U 
; 
call 
setSint; 
call 
unlock 
(7)'; 
return; 


end; 


end; 
/* 
of 
procedure 
*/ 


MODULE 
INFORMATION: 
CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


130 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


0108H 
DO 00il 
"\:lOCH 


264)) 
OD 
120 


Stitle('set 
interrupt 
routine') 


SetSi nt: 


do; 


/* 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


Set 
interrupt 
routine. 
Generates 
a 
level 
four 
interrupt 
on 
the 
b~s. 
Th~ 
semaphore 
associated 


4 
1 


5 
2 


G 
2 


7 
1 


'.' 
2 
v 
9 
2 


Hl 
1 


11 
2 


12 
2 
13 
2 
14 
2 
15 
2 
16 
2 


17 
2 
18 
2 
19 
2 


20 
1 


with 
the 
proc$id 
field 
is 
left 
set 
until 
the 
interrupt 


is 
serviced. 
An senaphore, 
level 
5, 
is 
set 
anct 
used 
as 


an 
indicator 
that 
the 
interrupt 
has 
been 
acknowledged. 


+ +++++++ 1-+++1-+++++++++++++++++++++++ 
+++++++++++ 
++++++ 1-++++ 


*/ 


S i nc1ucte (: E 1: 9 loba 1. ex t) 
/* 
Declarat.ion 
of 
global 
inter-processor 
data 
structures 
*/ 


de cIa re 
proc$id 
byte 
exte-rnal, 


I,ly$p id 
hyte 
external, 
in$que 
~ddress 
external; 
decla 
re 


my$proc$id 
literally 
'my$pid', 
intSproc$exch 
literally 
'in$que'; 


$ i nc Iud e ( : f I : se lTla 
• ext) 
lock: 
procedure 
(semaSid) 
external; 


declare 
sema$id 
byte; 


e nct; 


unlock: 
procedure 
(sema$id) 
external; 


declare 
sema$id 
byte; 
e nct; 


call 
lock 
(6) ; 
call 
lock(5); 
output(0E:BH)=0Fd; 
call 
lock 
(5); 
output(0E3H)=DEH; 
call 
unlock 
(5) ; 


call 
unlock 
(6); 
return; 
eoo; 


end 
set 
$ i nt ; 


MODULE 
INFOR~1ATION: 


CODE 
AR~A 
SIZE 


VARIABLE 
AREA 
SIZE 


IvlA,.{IIII1UH 
S'rI\CK 
SIZE 


49 
LI1\mS 
HF.:I\O 


o 
PROGRAi'1 ERfWR(S) 


o lJ22il 
00001l 
OIJ02H 


340 


00 
20 


$ tit 
Ie ( , I J:' I\C p'r 
r ou tine 
IPACP'r: 


do; 


/* 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


9 
1 


10 
1 


11 
1 
12 
1 


13 
1 


14 
2 
15 
2 


16 
1 
17 
2 
18 
2 


If 
no 
messaqe 
is 
queued 
at 
the 
exchanqe, 
a 
zero 
is 
returned. 


Else, 
a 
call 
is 
Made 
to 
IPWAIT 
to 
retrieve 
the 
first 
messaqe 
on 
the 
queue. 


+ ++++++++++ ++++++ +++ +++++++ ++++++.+++++ +++++++++++++++++++++++++ 


*/ 


$include(suspnd.ext) 
HQSlJSP: 


PHOCEDURE 
(T$PTR) 
EXTERNAL; 


DLCLAR F; 'r$PTR 
ADDRl~SS; 


£ND 
W1SUSPj 


$incluoe 
(msg. 
elt) 


DECLARE 
MSG$3DR 
LITERALLY 
, 
LINK 
ADDRESS, 
L£\IGTa 
ADDRESS, 


TYPE 
BYTE, 


HOMF;$EXCHANGE ADDRESS, 
RESPONSE$EXCll./\NGE 
ADDRESS'; 


DECLAHE 
IV\SG$Dt:SCRIPTOR 
LITERALLY 
STRIJC'l'UHE ( 


MSG$HDR, 
RE'''lAI(~DER(l) 
!:liTE) 
'; 


$ i ndude 
(task. 
el 
t) 


DECLAHE 
Ta.SK$DESCRIPTOR 
LI'l'ERALLY 
'S'rRUCTIJRE 
( 
DELAYS L I"IK$ FORWA1~DADDRESS, 
DELAY$LI\lKSBACK 
ADDRESS. 


'l'dREAD 
ADDRESS, 


DELAY 
ADDRESS, 
EXCdANGl~$ADDHCSS 
ADDRESS. 


SP 
ADDRESS. 


IV\ARKE:HADDRESS. 
PRIOHITY 
clYTE, 


STI\'l'US 
BYTE, 


NA~E$P'l'R 
ADDRESS, 


'l'ASKSLI 
"1K ADD!1I~SS) , ; 


$include(exch.elt) 
DECLAHE 
EXCHANGE$DESClUP'fuH 
LITERALLy 
'STHUCl'JRE: 
( 
MSG$HEAD 
ADDHESS, 


MSG$TAIL 
ADDRESS. 


'l'ASKSHEAO 
ADDRESS. 
'l'ASKSTAIL 
ADDRESS. 


NEXT$EXCd 
ADDRESS) 
'; 


$include 
(comnon.elt) 


DECLARE 
TRUE 
LITERALLY 
'0FFH'; 


DECLARE 
FALSE 
LITERALLY 
'0HH'; 


DECLAHE 
BOOLEAN 
LI'l'ERALLY 
'BYTE 
'; 


DECLARE 
FOREVER 
LITERALLY 
'WHILE 
I'; 


:;;i nc lude 
(: f 1: sema. 
ext) 
lock: 
procedure 
(sema$id) 
external; 


declare 
sema$id 
byte; 


end; 


unlock: 
procedure 
(sema$id) 
external; 


de cIa 
re 
sema$ id 
byte; 


end; 
$list 


IPWAIT: 
procedure 
(exchSadr,delay) 
address 
external; 
declare 
(exchSadr,nelay) 
address; 


end 
IPWAIT; 


declare 
exchS?tr 
address, 
(exch 
based 
exch$ptr) 
exchangeSdescriptor; 


24 
2 
call 
10ck (7); 


25 
2 
if 
exch.ms0She~d 
= 0 
then 


26 
2 
do; 


27 
3 
call 
unlock(7); 


28 
3 
return 
U; 


29 
3 
end; 


30 
2 
else 
do; 
31 
3 
call 
unlock(7); 


32 
3 
return 
IPWAIT(exch$ptr,0); 


33 
3 
end; 


34 
2 
end; 
/* 
of 
procedure 
*/ 
35 
1 
e nd 
I PACP'l'; 


~ODULE 
INFORMATION: 


CODE 
AREA 
SIZE 
vAlUABLE 
AREA 
SIZE 


,'1AXIMUM S'l'ACK SIZ8 
90 
LI!\IESREAD 


'" 
PHOGRAM 
ERROR(S) 


D0313H 
lHHHH-1 
0004H 


5~D 


0D 
4D 


S title ('Level 
4 
interrupt 
handler') 


Snointvector 
IntSproc: 


do; 


/* 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


This 
routine 
fields 
all 
level 
4 
interrnpts. 
If 
the 
global 
proc$id 
matches 
the 
local 
processor 
ID 
RQISND 
is 
called 


to 
awaken 
the 
intShnd 
task 
and 
the 
interrupt 
semaphore 
is 


cleared. 
If 
the 
processor 
10 
does 
not 
match, 
the 
Jnterrupt 


is 
iqnored. 


+ +++++++++++++++++++++++++ 
+++++ +++++++++++ +++++++++++++++++++++ 


*/ 


d ecla re 
rq14ex 
(15) 
byte 
external; 


if 
procSid 
<> 
mySproc$id 
then 
call 
rqendi; 


else 
do; 
proc$id=UFFli; 
ca 11 unlock 
(5) ; 
call 
rqisnd(.rqI4ex); 
end; 
r etu rn; 
end; 
/* 
or 
intSproc 
*/ 
end 
int$proc; 


MODULE 
INFORMATION: 


CODE 
AREA 
SIZE 


vARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
110 
LINES 
HEAD 


o 
PROGRAM 
ERROR(S) 


lHJ2AH 
OOODH 


0U0AH 


42D 
0D 
l0D 


$title('Interrupt 
nannler') 
Int$handler: 
do; 
/* 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


Interprocessor 
interrupt 
handler 
task. 
When 
notified 
by 
the 
Set$vec$4 
routine 
tha t 
the 
In$q ueue 
conta 
ins 
a 
task-message 
pair 
for 
this 
processor, 
the 
Int$handler 
task 
unqueues 


the 
task 
descriptor 
and 
resumes 
the 
task 
where 
it 
was 


suspended. 


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


*/ 


$ i nclu de ( : f 1 : 9 loba 1. ex t) 
/* 
DeClaration 
of 
global 
inter-processor 
data 
structures 
*/ 


de cIa re 
proc$id 
byte 
exte 
rnal, 
my$pid 
byte 
external, 
in$gue 
address 
external; 
declare 
my$proc$id 
literally 
'my$pid', 
int$proc$exch 
literally 
'in$que'; 


$include(:fl:sema.ext) 
lock: 
procenure 
(sema$id) 
external; 


declare 
sema$id 
byte; 
end; 


unlock: 
procedure 
(sema$id) 
external; 
declare 
sema$id 
byte; 
end; 
$ include 
(synch. 
ext) 


RQSEND: 
PROCEDURE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
EXTERNAL; 


DECLARE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
ADDRESS; 


12 
2 


13 
1 


14 
2 


15 
2 


16 
1 


17 
2 


18 
2 


19 
1 


20 
2 


21 
2 


22 
1 
23 
1 


24 
1 
25 
1 


26 
1 


27 
2 


28 
2 


29 
1 


HQ1-JAIT: 
PROCEDURE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS 
E:XTERNAL; 
OJ:,;CLARE 
(EXCHANGE$P01 
NTEH ,DE LAY) 
ADD RE:SS; 


HQACr'T: 
PROCEDURE 
(EXCliANGF.:$P01NTER) 
ADDHI,SS 
EXTE:RNAL; 
DECLARE 
EXCHANGF.:$POINTER 
ADDRSSS; 


RQISND: 


PROCEDURE 
(I8D$PTR) 
EXTERNAL; 


DE:CLARF.: I En$ PTR 
ADDRESS; 


END 
HQ1SND; 
$i nclune 
(coml:1on. el t) 


DECLARE 
-rrWF.: 
LITERALLY 
'0Fm'; 


DECLARE 
FALSE 
LITERALLY 
'0 0d'; 


DECLAHE 
BOOLEAN 
LITERALLY 
'BYTE'; 


DECLARE 
FOREVER 
LITERALLY 
'WHILE 
1'; 


$ include 
(re sume. ext) 


~'.QRE SM: 


'PROCEDURE 
(T$PTH) 
EXTERNAL; 


'. DECL.Z\RE 
T$PTH 
AD,DRESS; 


END 
RQHESlvJ; 


$ include 
(: f 1: ip task. 
el t) 


DECLARE 
I P$TASK$DESCRI 
PTOR 
LITI::AALL 
Y 
'STRUCrURE 
Dt;LAY$LINK$FOm-JARD 
ADDm; 5S. 


DELAY$ 
L 1>-11\$B AcK 
ADORE:S3 • 


TdHEAD 
ADDRESS. 


DELAY 
ADDRESS, 


£XCriANGE$ADDRESS 
ADDaESS. 


SP 
ADDRJ:,;5S • 


IvJARKER ADDRESS. 
PRIORIl'Y 
BYT!", 


STATUS 
BYTE, 


NAME$PTR 
ADDRESS, 


TASK$LINK 
ADDRESS, 
IP$THREAD 
ADDRESS) 
I; 


d ecla 
re 
rg14ex 
(15) 
byte 
ext.ernal; 


declare 
(msg$ptr, 
task$ptr) 
address; 


r:ls<]$ptr=rqwait(.rq14ex,0) 
;, 


call 
lock 
(7); 
if 
int$procSexch 
<> 
0 
then 
do; 


taskSptr 
= 
intSoroc$exch; 
int$proc$exch 
= 
11; 
e nc'I ; 
else 
call 
unlock 
(7) ; 
call 
rqresm 
(taskSptr) 
; 
end; 
/* 
of 
do 
forever 
*/ 
end; 
/* 
of 
task 
*/ 
end 
i ntShancHe 
r; 


MODULE 
I~POR~ATION: 
CODE 
AHEA 
SIZE: 
VAUIABLE: 
AREA 
SIZE 
MAXI~UM 
STACK 
SIZE 
lU8 
LINES 
READ 
" 
t>ROGRAJ'1 ERROR(S) 


01J3DH 
0004C:1 
0002:-I 
-c 


610 
40 
20 


Stitle('Global 
Initialization. 
Version 
1.1') 
globalSinit: 
do; 


/* 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


This 
is 
an 
initialization 
routine 
that 
is 
called 
hy 
only 
one 
of 
the 
procesoors 
in 
the 
system. 
It 
initializes 
those 
structures 
that 
must 
be 
initialized 
before 
any 
II? 
routines 
are 
used 
and 
must 
then 
be 
lef.t 
alone. 


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


*/ 


$i nc1ude (:fl: 
irexch.elt) 
DECLARE 
IP$EXCHANGESDF:SCRIPT'JR 
LITEHALLY 
'STRUCTUR£ 
( 


!'1SG$HE:AD 
I\DDRESS. 
MSGs'rAIL 
ADDRESS, 
TASKSHEAD 
AlJJRESS. 
TASK$TAIL 
ADDRESS, 
NI=;}{'rS EXC:l 
ADDReSS. 
R8SERVED 
(10) 
BYTE, 
I~$TASK$HEAD 
ADDRESS. 
IPSTASK$TAIL 
ADDRESS) 
'; 
$i nc1ude (:f 1: global. 
ext) 
/* Declaration 
of 
global 
inter-processor 
data 
structures 
*/ 


declare 
proc$id 
byte 
external, 
mySpid 
byte 
external, 
i nSque 
add ress 
exte 
rnal; 
decla 
re 
['lySprocSid 
lit 
erall 
y 
'[.ly$pid', 
intSprocSexch 
literally 
'in$que'; 


decla re 
ip$exchStab 
address 
external, 
ip$exch 
(1) ip$exchange$de 
scr iptor 
at (.ipSexch$ tab) , 


num$ip$exch 
byte 
external; 
declare 
semaphore(8) 
byte 
external; 


intSpr ocSexch=U; 


/* 
initialize 
user 
ip$exch 
decsri9tors 
*/ 
do 
i=U 
to numSip$exch-l; 
ip$exch (i).ip$task$hea 
d=t:J; 
ip$exch (i). 
ip$task$ tai 1=. ip$exch (i) ; 


end; 


do 
i=U 
to 
7; 
semaphore 
(i)=0; 
end; 


return; 
end; 


MODULE 
INFORMATION: 


CODE 
AREA 
S IZ E 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


73 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


(J075tl 
000lH 
U002H 


l17D 
lD 
20 


$title('LOCK 
and 
UNLOCK 
procedures, 
Version 
1.1 
) 


SEMA: 
do; 


/* 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


These 
procedures 
provide 
mutual 
exclusion 
on access 


to global 
data 
structures 
used 
in 
the 
interprocessor 


communication 
package. 
Both 
routines 
use 
the 
seventh 


semaphore 
for 
global 
data 
and 
the 
sixth 
semaphore 
for 
interrupts. 
Softwa~e 
semaphores 
are 
used. 


11 
1 


12 
2 
13 
2 


14 
2 
15 
2 
15 
3 
17 
3 
18 
3 
19 
3 


20 
3 


21 
3 


22 
2 
23 
2 


*/ 
$i nclude 
(exch. 
el t) 
D~CLARR 
EXCHANGE$D8SCRIPTOR 
LITERALLY 
'STRUCTURE 
( 


MSG$HEAD 
ADDRESS, 
MSr,$TAIL 
ADDRESS. 
'rASK$HE:AD AODRESS, 
TASK$TAIL 
ADORE:SS, 


NEXT$EXCH 
ADDRESS) 
'; 


rqwait: 
proceciure(exch$ptr,cielay$time) 
address 
external; 


declare 
(exch$rtr,delay$time) 
address; 
end 
rqwa i t; 


s$mask: 
procedure 
(mask) 
external; 
decla 
re 
mask 
byte; 
end 
s$mask; 


declare 
timout 
exchange$descriptor 
external; 
declare 
se8~phore(8) 
byte 
external; 


/* 
loc!< 
procedure 
called 
upon 
entry 
of 
code 
modifying 


data 
structures 
*/ 


declare 
(sema$num,semC\) 
byte; 
declare 
(mem$ptr) 
address; 


serna=l; 
do 
while 
sema=l; 
mem$ptr=rqwai 
t(. 
ti 
mout,l); 
call 
s$mask(0COQ); 
serna=semaphore 
(serna$num); 
semaf)hore 
(semil$num)=0FFl-l; 
call 
s$mask 
(0401'1); 
end; 
r etu rn; 


e nd; 
/ * 
0 f 
LO C T< */ 


semaphore 
(sema$num) 
=0; 
r etu rll ; 
e rd; 
/* 
of 
unlock 
*/ 


MODULE 
INFORMATION: 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


67 
LINES 
READ 


o 
PROGRAM 
E:RROR(S) 


005F:i 
(JOOOH 


(H) 0f5H 


950 
00 
nO 


$ title 
(. ip$INIT 
in it ial 
izat 
ion 
rou ti ne .) 
I p$ i ni t: 
do; 
/* 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


Initialization 
routine. 
Creates 
HQL4EX, initializes 


the 
interrupts 
and 
the 
interrupt 
handlers 
and 
creates 


the 
interrupt 
task 
int$hnd. 


+++++++++++++++++++-+++++++++++++++++++++-++++++++++++++++++++++++ 


*/ 


4 
1 


5 
2 
6 
2 


7 
1 


8 
2 
~ 
2 


34 
1 


35 
2 


36 
1 


37 
2 


38 
1 


$ i n elude 
( : [ 1: g 10ba 1. ex t) 


/* Declaration 
of 
global 
inter-processor 
data 
structures 
*/ 


declare 
proc$icl 
byte 
external, 
lny$pid 
hyte 
external, 
in$que 
address 
external; 
declare 
rny$proc$id 
literally 
'my$pi~'. 
intSprocSexch 
literally 
'inSque'; 


$ i nc 1II de ( : f 1: se ma• ext) 
lock: 
procedure 
(semaSid) 
external; 
de cIa re 
serna $ id 
byte; 


e nr'l.; 


unlock: 
procedure 
(sema$id) 
external; 


decl"re 
semaSid 
hyte; 
end; 
$nolist 


i nt$hhcl: 
proce<'lu re 
exte 
rna 1; 


end 
int$hn<'l; 


set$vec$4: 
procedure 
external; 
ends 
e t $ve c $4 ; 


declare 
i nt$hnd$s 
tl 
Ii te ra lly 
'00', 
intShno$stk 
(intShno$stl) 
byt.e, 
int$hndStd 
(20) 
byte, 
rql4ex 
(15) 
byte 
public, 
i n t :;;hn d$p r i 
1i t era 11y 
,G5 I 
; 


ded"re 
int$hnd$std 
static$taskSdescriptor 
data( 
'inthnd', 
• intShnd, 
· in t$hndSs 
tk, 
i nt Shn d$ s tl , 
i nt$hn<'lSpr 
i, 
0, 
· int$hndSt(1); 


/* wait 
for 
sooeone 
to 
perform 
global 
initialization 
and 
reset 
semarhores 
*/ 


call 
lock 
(7) ; 


call 
unlock 
(7) ; 


output(OEBd)=80H; 
ou tput 
(DEWI)= DEH; 


call 
rqcxch(.r4l4ex); 


ca 11 
rqct:3k 
(. i n tShnd$s 
tel) ; 


call 
rqsetv 
(. set$vec$4, 
4) ; 


call 
rqelvl(4); 
r etu rn ; 


end; 
/* Ot 
procenure 
*/ 


MODULE 
INFORMATION: 


CODE 
AREA 
SIZE 


VAHI~BLE 
AR8A 
SIZE 
MAXI~UM 
STACK 
8I7.8 
133 
LllllES 
HEAD 
o 
t'ROGRA'1 
ER1WR(S) 


003DH 
005Fd 
0002H 


610 
950 
20 


APPENDIX B 
BIPI PROGRAM LISTING 


$TITLE('RMX/BASIC 
MULTIPROCESSOR 
INTERFACE, 
VERSION 
1.1') 
/**************************************************************** 
* 
BIPI 
* 
* 
T!-\IS 
IS 
TtiE 
INTERFACE 
BETWEEl\l 
'fT-IE RI\1X/BASIC 
PROCESSOR 
I\ND * 


* 
THE 
I,\ULTI-PROCESSOR 
WORLD. 
THE 
R"1X/BASIC 
INTERPORCESSOR 
* 


* 
INTERFACE 
(BIPI) 
IN'rEHFACES 
'fO 
THE 
TERMINAL 
HI\NDLF:H 
AND 
'1'0 
* 
* 
'r9E 
DISK 
10 
SYS'rEM. 
'rHE 
BI1'I 
f){JP1'ORT 
'l'HE 
RECF:IPT 
OF 
THE 
* 
* 
fOLLOWING 
MESSAGE 
TYPES: 
* 


* 
* 
* 
TERMINAL 
HANDLER 
REQUES'l'S: 
* 
* 
R EAD$TYPE 
8 
READ 
FRO"1 TERMIN AL 
* 
* 
WHHE$TY?E 
= 
12 
WRITE 
TO 
TERMINAL 
* 


DISK 
I/O 
SYS'l' F:)Vl 


DFS$RJ) 
DFS$W'l' 
DFS$Sl< 
DFS $CLS 
DFS$OPN 


REN) 
FROIl1 DISK 
vJl1IT E TO 
/) ISK 
DISK 
SEEK 
OPERATION 


DISI< 
FILE 
CLOSE 
DISK 
FILE 
OPEN 


REQUES'l'S: 
72 
76 
77 
78 
79 


* 
* 
* 
BASIC 
'f/\SK 
C01VllVlANDHEQUEs'rs: 
* 
* 
SUSBAS 
128 
SUSPEND 
BASIC 
TASK 
* 
* 
RESI3AS 
= 
129 
RESU"\E 
BASIC 
TASK 
* 
* 
* 
* 
* 
* 
THE 
TASK 
WI LL 
BE 
ENTERED 
13Y SENDING 
THE 
NORMAL 
REQUEs'r 
MES- 
* 
* 
SlICE 
'fa 
TriE 
GLOBAL 
EXCHANGE 
8IPI$EXCti. 
* 
****************************************************************/ 


DECLARE 
READ$TYPE 
LITERALLY 
'8'; 
DECLAHE 
WnITB$T'iPE 
LITERALLY 
'12'; 


DECLARE 
DFS$RD 
LITERALLY 
'72'; 
DECLAHE 
DFS$WT 
LITERALLy 
'76'; 


DECLARE 
DFS$SK 
LITERALLY 
'77'; 


DECLAHE 
DFS$CLS 
LITERALLy 
'78'; 
DECLARE 
DFS$OPN 
LITERALLY 
79'; 


DECLARE 
SUSBAS 
LITERALLY 
'128'; 
DECLARE 
RESBAS 
LITERALLY 
'129'; 


DECLARE 
(MSG$PTR,RESPONSE$PTH) 
ADDRESS; 


D8CLARE 
(TYP E) 
BYTE; 


RQSEN/): 
PROCEDURE 
(8XCH$PTR,J"iESSAGE$PTH) 
Ex'rERNAL; 
DECLAHE 
(EXCti$PTR,MESSAGE$PTR) 
ADDRESS; 
END 
HQSBND; 


RQWAIT: 
PROCEDURE 
(EXCH$P'I'H,TIiVlEOUT) 
ADDRESS 
EXTERl\lAL; 


DECLAHE 
(EXCH$PTR 
,'rIMEOUT) 
ADDRESS; 
END 
RQWAIT; 


HQSUSP: 
PROCEDURE 
(TASK$DESC$PTR) 
EXTERNAL; 
DECLARE 
(TASK$DESC$PTR) 
ADDRESS; 
END 
RQSUSP; 
RQRESM: 
PROCEDURE 
(TASK$DESC$PTR) 
EXTERNAL; 
DECLARE 
(TASK$DESC$P'l'l{) 
ADD1<ESS; 
END 
RQRESM; 


/* DEFINE 
INTER-PROCESSOR 
PROCEDURES 
USED 
AY 
THE 
TASK 
*/ 


IPSBND: 
PROCEDURE 
(EXCH$PTR,J'1ESSAGE$p'rR) 
EXTERNAL; 
DECLAHE 
(P.XCH$PTH,lvlF;SSAGE$PTR) 
ADDRESS; 
END 
IPSEND; 
IPWAIT: 
PROr.EDURE 
(EXCHSPTR,DUMMY) 
A~)RESS 
EXTERNAL; 
DEC Ll\RE 
(EX<;:H $ PT H, OUJ'1MY) ADD RE5S; 
END 
IPWAIT; 
IPINIT: 
PROC EDURE 
EXTE RNAL; 
END 
IPINIT; 


SET$VECS4: 
PROCEDURE 
EXTERNAL; 
END 
SE'!'SV8CS4; 


/* 
DEFINE 
THE 
EXCHANGES 
REQUIRED 
BY 
THE 
TASK 
*/ 


SINCLUDE 
(:Fl:EXCrl.DEF) 


DECLA~E 
EXCHANGE$DESCRIPTUR 
LITERALLY 
'STRUCTURE 


MESSAGE$H8AD 
ADDRESS. 
MESSAGE$TAIL 
ADDRESS. 
TASK$HEAD 
ADDRB SS, 
TASK$'l'AIL 
ADD RESS. 
EXCHANGE$LINK 
ADDRESS) 
'; 
DECLARE 
INT$EXCdANGESDE:SCRIPTOH 
LITE:RALLY 
'S'!'RUC'fURE 


MESSAGE$HEAD 
ADDRESS, 
MESSAGESTAIL 
ADDRESS, 
TASK$HEAD 
ADDqESS, 
TASK$TAIL 
ADDRESS. 
EXCHl\NGE$LINK 
ADDRESS. 
L IJIjK 
ADORE S8. 
LENGTH 
ADDRESS. 
'!'YPE 
BYTE 
),'; 


DECLAHE 
AIP IS EX 
EXCi-fANGE$DESCRI 
PTOH 
EXTERNAL; 
DECLARE 
RQ INPX 
EXCHANGE$DESCHIPTOR 
EXTERNAL; 
DECLAHE 
RQOU'fX 
EXCHA1'JGE$DESCRIPTOR 
r:;XTERNAL; 
DECLAHE 
RQOPNX 
EXCH ANG ESDESCRI 
PTO R 
EXTE RNAL; 
DECLARE 
BIPISRE 
EXCHANGESDESCRIPTOR 
SXTERNAL; 


/* DEFINE 
TqE 
BASIC 
MESSAGE 
STRUCTURE 
OF 
INCOMING 
MESSAGES 
*/ 


DECLARE 
i'1SG BASED 
MSG$PTR 
s'rRUCTURE 
L INK 
ADORE 55 • 
LENGTH 
ADDRESS. 


TY~E 
BYTE, 
dOMES EXCi-lANG E 
ADDRESS. 
RESPONSESEXCHANGE 
ADDRESS 
); 


BIpI: 
PROCEDURE 
PUBLIC; 


/* AT 
INITIALIZATION 
WAIT 
FOR 
COMMUNICATIONS 
PROCESSOR 
'ro 
COME 
UP * / 


MSGSPTH 
= 
RQ1>JA1T(.8IPISRE, 
100); 
Cl\LL 
IPS INI'f; 


DO 
WHILE 
1; 


/* WAIT 
FOR 
A 
REQUEST 
FROM 
A 
PROCESSOR 
ON 
BUS 
*/ 


MSGSPTR 
= 
IPWAI1' 
(.BIPISEX,0); 


RESPONSESPTR 
= 
MSG.R8SPONSESEXCHANGE; 
MSG.RESPONSESEXCHANGE 
= 
.8IPISRF.; 


IF 
TYPE 
= 
REAOSTiPE 
THEN 
CALL 
HQS8ND 
(.RQII,>/PX,I\1SGSPTH); 


IF 
TYPE 
= WRITE$TYPE 
TH8N 
CALL 
RQSEND 
(. RQOUTX,.M SGSPTH); 


IF 
'ryp E 
> 
71 


·rHEN 
MSG.T'ft>F. 
= 
MSG.TYPE 
- 
64; 


IF 
TYPE 
= DFSSOPN 
THEN 
CALL 
RQSEND 
(.RQOPNX, 
MSGSPTR); 


If 
«TYPE> 
71) 
AND 
(TYPE 
< 
79)) 
THEN 
CALL 
RQSEND 
(MSG.HOMESEXCHANGE,MSGSPTR); 


IF 
TYPE> 
127 


THEN 
DO; 


IF 
'l'YPE 
= 
SUSI3AS 


'rHEN 
CALL 
RQSUSP 
(BASC$TD); 


IF 
TYPE 
= 
RES8AS 
THEN 
CALL 
RQRESM 
(BASCSTD); 


/* 
SWI\P 
RESPONSE 
EXC!'IANGES 
AGAI'~ 
BEFORE 


RETURNING 
MESSAGE 
*/ 


MSG. RE SPON SE $ EXCHANG E 
= 
HF.:SPONS~~$ PTR; 


/* 
RETURN 
THE 
J'1ESSAGE TO 
'f:I£ 
CALLING 
PROGRA,"1 */ 


END; 


El~D 
SIPI; 


END 
BIPI$MODULF.:; 


CODE 
AREA 
SIZF.: 


VARIABLE 
AREA 
SIZE 
MAXIMUM 
STACK 
SIZE 


206 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


0101H 
00 lJ5d 
000211 


257D 
5D 
20 
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System designers are satisfying more and more difficult 
application needs with solutions which use microproces- 
ors in a distributed 
environment. 
This distribution 
of 


intelligence results in many system benefits, including a 
simplification of the design and a resulting decrease in 
the development time of the system ·solution. An addi- 
tional feature is the minimization 
of the installation 


costs of the system resulting from reduced wiring and 
from resource sharing. However, to effectively create 
distributed solutions, a reliable communication 
scheme 


must be used which links the various parts of the solu- 
tion together. 


The purpose of this application note is to demonstrate 
the ease with which Intel iSBCTMboards can be config- 
ured to implement 
distributed 
solutions. 
Several ap- 


proaches are offered which apply standard 
operating 


modes of both the hardware and of the software. While 
certainly not the only solution, a distributed processor 
communications 
protocol is developed which will sup- 


port many typical applications. 


Qistributed systems generally fall into one of two cate- 
gories. The first consists of those systems in which the 
processors are located in such a manner as to allow com- 
munications over a common system data bus, such as 
Intel's MULTIBUSTMsystem bus. The second category 
involves systems in which the processors are also geo- 
graphically distributed. 
This class of system generally 
uses a form of serial communications to allow each pro- 
cessor to communicate 
with other processors 
in the 


system. 


The emphasis of this application note is on serial multi- 
processing links. Before proceeding with a development 
of application solutions which involve serial communi- 
cations, this note includes a short discussion of common 
network designs. 


Common Network Designs 


Serial networks may be classed into three general cate- 
gories. These are the LOOP, the MULTIDROP, 
and 


the STAR. Each has applicability to certain iSBC prod- 
ucts and has distinct advantages and disadvantages in an 
application. After discussing the characteristics of each 
network, an application scenario illustrates their uses. 


The loop represents the most common of the communi- 
cation schemes. It is derived from the older teletype 
communication networks in which several printers were 
connected in series. Any data generated on one machine 
causes all machines concerned in the network to echo 
the data. This arrangement is shown in Figure I. Loop 
communications 
normally use a 20-milliamp signal to 


convey the data. The presence of this current, known as 


marking, represents a binary I and the absence, or spac- 
ing, of any circuit (an open circuit) represents a binary 
O. Both full and half duplex configurations 
are com- 


monly used. 


The incorporation 
of loop networks into a system im- 


plementation 
creates both advantages 
and disadvan- 


tages. The strongest argument for using a loop is the 
inherent noise immunity which can be gained by using 
the 20-milliamp current to convey the data. The use of a 
high compliance voltage also allows the transmission of 
data for large distances at low to moderate transmission 
rates. 


Solid state circuits common to current technology are 
somewhat less reliable than older mechanical units when 
many stations are configured onto the loop. This is the 
result of the requirement to reproduce the information 
at each node for transmission to the next node. If any 
node fails, all other nodes downstream in the communi- 
cation network will not be capable of communicating. 
Even with this constraint, many good designs incorpo- 
rate the loop network concepts. 


Multidrop networks are fast becoming the accepted net- 
work for multiprocessor communications. 
This type of 


network is shown in Figure 2. As can be seen, this ar- 
rangement is similar to that of the loop. The advantage 
is that all stations are capable of receiving data simulta- 
neously. Multidrop networks are voltage driven since to 
pass current through a node creates a loop situation. 
The electrical interface for multidrop networks consists 
of tri-state drivers and high impedance receivers. The 
RS422 electrical interface is common for this type of 
network since it provides high speed data transmission 
over long distances with good noise immunity. 


inter 


The ability to implement networks 
with a minimum 


amount of hardware and the potential expansion capa- 
bilities provide the multidrop network with a significant 
advantage in many applications. Since each node in the 
network can be added by simply adding another tee net· 
work, 
expansion 
is performed 
without 
the need for 


modification of the communication 
network. 


Intel's iSBX 35JTMSerial MULTIMODULETM Board is 
an ideal vehicle for the implementation 
of multidrop 


networks. Its use is detailed in subsequent paragraphs of 
this application note. 


Star 
networks 
are 
implemented 
where 
either 
data 


throughput 
or hardware limitations prohibit the use of 


other types of communication 
arrangements. 
Figure 3 


illustrates a typical star network implementation. 
Note 


that a star network is really an example of multiple 
point to point communications. 
System throughput 
is 


improved since communication can occur with all slave 
nodes simultaneously 
without the need to have each 


node monitor traffic which is not intended for it. 


Intel's 
iSBC 544™ Intelligent Communications 
Con- 


troller and the iSBC 534™ Four-Channel 
Communica- 


tions Board are ideal choices to design star communica- 
tions networks. 
The outer points of the star are im- 


plemented using any single board computer which has 
on-board 
serial communications. 
An example of this 


type of network is included in this application note. 


Sample Application 


An application example is used in this application note 
to illustrate the techniques which are required to imple- 
ment various types of serial communication 
networks. 


Both hardware and software aspects of the design are 
described in some detail. 


The application discussed in this note involves the crea- 
tion of an alarm and security system for a multiple 
building complex. This complex is shown in Figure 4. 
The solution generated allows monitoring of three exist- 
ing buildings with provision for the addition of a fourth 
at a later date. The figure shows that each building is to 
have a local annunciator 
panel for reporting activity in 


those areas served by the building sensors. In addition, a 
main security station provides monitoring of all build- 
ings in the complex. 
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Applications such as this are optimized by distributing 
the system intelligence throughout 
the complex. This 


serves two needs; that of minimiz;ng the wiring costs, 
and of providing an improvement in system reliability. 
When a system is distributed in this way, a means must 
be devised which allows communication 
between the 
various elements of the network. 
Both hardware 
net- 


work design and software communication 
protocol are 


required before the system can be considered opera- 
Figure 3. Star Configuration 
tional. 


inter 


In order to illustrate various network designs, the exam- 
ple is broken into a distributed system as shown in Fig- 
ure 5. This is an example of a multidrop communication 
network. The system design does not require that build- 
ing nodes communicate with each other; all communica- 
tions are between building annunciator 
nodes and the 


main operator station. This illustrates the concept of a 
master and a slave. This will be further discussed in a 
later portion of this application note. 


The building annunciator 
can be further distributed as 


shown in Figure 6. Here, a star communication network 
is created which places data gathering intelligence near 
clusters of sensors. These stations, or nodes, then trans- 
mit information 
regarding local activity to their master 


node, 
the 
building 
concentrator/annunciator 
panel. 


Note that this panel serves both as a master node for the 
sensor units and as a slave node for the main operator 
station. This arrangement 
is common in many system 


designs. 


• THE 
USEJI OF CLUSTER 


SENSOR 
INTERFACE 
CONCENTRATO"S 
MINIMIZES 
WIRING 
COSTS 


• HIGH 
SPEED 
SERIAL 
liNKS 
"EPlACE 
MULTIPLE 
SENSOR 


WIRING 


• SYSTEM 
INTEGAITY 
IS 


ENHANCED 
IY 
LOCAL 
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At 
COMMUNICATION 
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The implementation 
of communication 
networks using 


iSBC boards for both star and multidrop techniques is 
detailed 
in the following 
sections. 
In each case, a 


master/slave 
relationship is assumed. For purposes of 


illustration, actual data from the application example is 
used in performing the sample calculations. While not 


the only possible system designs, those shown are con- 
sidered to be typical and should enable the reader to 
gain an insight into techniques which can be used to 
create similar designs. 


Star Network Design 


A star network can use almost any accepted transmis- 
sion media. This is because each node communicates 
with only one other node, creating a multiple point to 
point link. Since the techniques 
are identical for all 


media, this note discusses only a representative 
exam- 


ple. RS232C data transmission is used to demonstrate 
the techniques which can be used to establish a star net- 
work. 


The heart of a star network is the master node. It must 
provide a means of independent 
communication 
with 


each of its slave nodes. Costs can be minimized if multi- 
ple communication 
drivers are placed onto the same 


board. 
The example chosen requires that 
four slave 


nodes be controlled by the master. The iSBC 544 Intelli- 
gent Communications 
Controller 
provides this func- 


tion. It provides a software selectable baud rate and the 
ability to offload the host processor of communication 
activities. If additional 
slave nodes are required, 
the 


system can be expanded by adding iSBC 544 controller 
boards. 


An ideal choice for a slave node is the iSBC 80/IOBTM 
Single Board Computer. 
This computer provides good 


processing capabilities with low cost. It includes both an 
RS232C and 20-milliamp current loop communications 
interface. For many small applications it makes an ideal 
choice for a complete single board solution. 


Figure 7 shows the implementation for a four-node plus 
master star communication network for the security ap- 
plication. 
Both the iSBC 544 communications 
board 


and the iSBC 80/l0B 
Single Board Computer require 


jumpering and component insertion to allow operation 
in either the RS232C mode or in the EIA mode. EIA 
operation 
is electrically identical to RS232C but has 


specifications which allow transmissions 
at significant 


distances when the baud rate is reduced. For the pur- 
poses of this application note, the terms are used inter- 
changeably. 


inter 


In the case of the iSBC 544 board, a header plug can be 
inserted into an on-board connector to enable the cor- 
rect mode of operation. 
The wiring for this header is 


shown in Figure 8. Note that the ready to send and the 
clear to send signals are jumpered to allow the correct 
operation of the USART without the control signal of a 
modem. Also note that the transmit and receive signals 
are reversed through the header. 


The use of an RS232C signal for long distance com- 
munication necessitates the use of a low baud rate for 
reliable data transmissions. 
This is shown in Figure 9. 
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The security system application design allows for mini- 
mum communication 
traffic so a baud rate of 1200 is 


used for the star networks. 
The placement of intelli- 
gence at the sensor cluster minimizes the amount of data 
which must 
be transmitted, 
providing 
adequate 
re- 


sponse time at this data rate. 


The hardware design phase includes the selection of the 
communication scheme to be used between the host pro- 
cessor and the slave node. 
Fortunately, 
this task is 


simplified by the use of built-in master/slave 
protocol 


functions contained on the iSBC 544 communications 
board. These functions involve three hardware features. 
The first is the incorporation 
of dual-ported 
memory 


onto the board. This memory provides a media for the 
storage of data and commands for communication 
be- 


tween the slave and the host processor. 
The second 


feature generates a flag interrupt 
each time the host 


board writes into the first location of the dual-ported 
memory. The interrupt is cleared when the memory lo- 
cation is read by the slave processor. Finally, the execu- 
tion of the 8085A-2 SOD instruction generates a MUL- 
TIBUS interrupt to inform the host board of the need to 
service the slave. This interrupt can be vectored to the 
host interrupt matrix to activate a service routine in sup- 
port of the slave board. 


A detailed explanation 
of the use of these features is 


found in another 
application 
note, AP-53, Using the 
iSBC 544™ Intelligent 
Communications 
Controller. 


The reader should refer to this document for details of 
the board and its use. 
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Multidrop 
Network Design 


The c01Ilplexity of a multinode 
system is minimized 


through the use of a multidrop network. Certain limita- 
tions are placed on the acceptable hardware transmis- 
sion media in multidrop applications. A scheme must be 
used which allows each of the nodes to alternatively gain 
control 
of the network 
in order to communicate 
its 


message. 


Both half and full duplex configurations 
are allowable, 


in a multidrop network. While it is simpler from a hard- 
ware standpoint, 
a half 
duplex connection 
requires 


more stringent communications 
protocol as this system 


allows communications 
in only one direction at a time. 
For all practical purposes, 
no priority for masters or 


slaves is provided. All nodes may listen to whomever is 
using the line at the time. The software must be written 
to allow only one node to communicate 
at a given 


instant. 
An example of a half duplex network is the 


Ethernet. 


More straightforward 
software can be written for full 


duplex communication configurations. 
In this instance, 


HEADERS 


XU •• AND xus 
r-------; 


BUFFER 
U1 
r------: 


J 


an assumption is made that only one master is config- 
ured into the system and always drives the output lines. 
Any number of slaves can be placed to drive the input 
lines, communicating only when queried by the master 
node. This is the scheme used for the application exam- 
ple which is discussed in this application note. 


Intel's iSBX 351 Serial MULTIMODULE 
Board lends 


itself well to a multidrop application. 
It allows a wide 
variety of system solutions to be created using any of the 
single board 
computers 
which incorporate 
iSBX bus 


connectors. 
Several board options must be enabled to 


create the multidrop communications 
configuration. 


The first option involves configuring the drivers to use a 
tri-state driver on the output lines. This allows only the 
board desiring to control the communications signals to 
place data on the serial output lines. The board config- 
uration is different for a slave and for a master node. In 
the Intel implementation, 
the driver output signal lines 


are controlled 
using the DTR (data terminal 
ready) 


signal from the USART. The jumper configuration 
for 


both a slave and a master is shown in Figures 10 and 11. 
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Figure 
12 illustrates 
the physical wmng 
data 
paths 


which are used to create a full duplex multidrop net- 
work having a master and four slave stations. 
Each 


board must be configured using a header block to pro- 
vide the correct signals. This is done as shown in Figures 
10 and 11. 


Finally, bias resistors are chosen to terminate the serial 
communication 
data paths. A discussion or the formu- 
las for determining 
the correct 
values for the two 


resistors is provided in Appendix A of the iSBX 35l™ 
Serial MULTIMODULE 
Board Hardware Reference 


Manual (Order Number 9803190). If the equations are 
solved for the componnts used on the RS422 section of 
the board, 
the equations 
for calculating 
the correct 


values become: 


The drivers used on the iSBX 351 communications 
MUL TIMODULE 
board 
limit the number 
of slave 


nodes to II for anyone network. If greater numbers of 
nodes are required, 
a driver component 
substitution 


may be required. 


For the example application 
in this note, four slave 


nodes are used, so the calculated resistor values become 
370 ohms for RbI and 205 ohms for Rb2. 


Figure 13 illustrates the acceptable baud rates for vari- 
ous communications 
cable lengths using the RS422 in- 
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terface. The iSBC 351 board is designed to support data 
transmission 
rates of up to 19.2 kilobaud. 
Thus, the 


system designed using these boards is seen to permit a 
total multidrop cable length of up to 4000 feet (1.219 
km). The sample application discussed in this note in- 
corporated a total communications 
link length of 1600 


feet, well within the performance limits. 
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Once the hardware has been defined, the design process 
moves into a' software phase. Here, protocols are de- 
fined which provide both data transmission and hand- 
shaking 
between 
nodes. 
Handshaking 
is defined 
as 


background 
communication 
which maintains synchro- 


nization 
and 
integrity 
of the communications 
link. 


IRO sol 


10M Rsl 
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inter 


Again, standard features of both iSBC board products 
and of iRMXTMsoftware products simplify the incorpo- 
ration of communication protocols into the system solu- 
tion. 


Master/Slave 
Relationships 


In order to maintain an orderly flow of data between 
nodes, software must be created which allocates priority 
and only allows one node to transmit at any instant. The 
most straightforward 
technique which incorporates this 


function 
is the master/slave 
relationship. 
Here, one 


node is designated as a master and all others are slaves. 
Each slave is allocated a time during which it may trans- 
mit any information 
to other nodes. The master node 


controls the prioritization 
of all slave nodes. The com- 


plexity of the system can be further reduced if a full 
duplex scheme is implemented. In this mode, all slaves 
listen only to the master and transmit their messages 
over a common serial channel to the master. A disad- 
vantage of this technique is that direct slave to slave (vir- 
tual channel) transmissions are not permitted. 


Figure 14 shows how a master node establishes time 
slots for windows, during which a slave may control the 
output channel and transmit data to the master. Each 
slave node is assigned a unique identification or address. 
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Each data packet contains an address as an integral 
part. When a slave recognizes its address in the packet 
from the master, it knows that it has fIxed time window 
in which to return its own data packet to the master. 


Communications 
between each slave and its master in- 


volve the transmission 
of data packets. 
Each packet 


contains both handshaking information 
(such as check- 
sums and message counts) and the information which is 
to pass between nodes. The handshaking portions of the 
message are used to maintain the integrity of transmis- 
sions in the face of such external stimuli as electrical 
noise. 


Debugging and system maintenance is minimized when 
a means is provided which allows easy viewing and in- 
terpretation 
of 
the 
communication 
messages. 
The 


scheme used in this application note uses a fully ASCII 
compatible communications format. This allows a CRT 
terminal to tap onto the link and to monitor all com- 
munication messages. 


Each message packet begins and ends with a unique 
character. 
This character cannot exist with a message 


block. Using the ASCII formats, 
all messages use the 


numeric representation 
of 0 to 9 and the alpha charac- 


ters from A to Z. A line feed is used to begin a message 
packet and a carriage return is used to terminate the 
message. The assignment of these characters assures an 
easily interpreted message packet. 


The layout of the data packet is shown in Figure 15. The 
justification and description of each field is given in the 
following paragraphs. Note that much of the message is 
concerned with maintaining 
system integrity. 
The re- 


quirement 
for an address field has already been de- 


scribed. Two characters are used for this fIeld and pro- 
vide for 256 addresses (O-FF hex). The protocol being 
described used 0 as the system master and 1 through 255 
for possible slave addresses. 
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The next field indicates the type of message being sent 
and the action which is required by the receiver. Anal- 
ysis of system communication 
requirements 
indicate 


that five message types are sufficient. The use of a single 
byte of the packet for this field allows a total of 16 
message types. This leaves 11 for future expansion. The 
types being used in this application are: 


Type 0 - 
This is a reset request from the master to 
a slave. It will cause the target slave to generate a 
software reset. This command is used only when 
communications cannot be established using other 
means. 


Type 1- 
A type 1 command is used to synchro- 


nize the master and the slave. It will cause the 
message counters (see subsequent paragraphs) 
to 


reset to zero. This command is issued only by the 
master node. 


Type 2 - 
The type 2 message is defined to be that 


which contains information 
which is to be moved 
between nodes of the communications 
network. 


The exact format of the data is discussed else- 
where. This is the only message which is not con- 
sidered to be of a strictly handshaking nature. 


Type 3 - 
A type 3 message is used to indicate that 


a network node is responsive and ready to handle 
messages. 
When 
normal 
communications 
have 
been established and no data messages are being 
sent, this message is continuously being sent be- 
tween the master and the slaves. 


Type 5 - 
The final message type is the type 5. It is 
used by the slave to respond to the master's re- 
quest to synchronize. The receipt of this message 
indicates 
that 
the 
slave 
has 
performed 
all 


necessary operations 
with its message counters 


and is ready to receive messages. 


The next field is used to describe the number of mes- 
sages which contain data and have been received or sent 
by each node. The first character is used to indicate the 
number of messages which have been received from the 
master node to that slave. The second character indi- 
cates the number of messages which have been sent 
from the master to the node. Internal software protocol 
enables the communications package to use these fields 
to determine if a data message has been received cor- 
rectly by the target node. If a response message does not 
contain the correct counts, the message can be retrans- 
mitted. Since only one character is used for each count, 
the numbers are allowed to recycle each 15 messages. 


The data field contains information which is to be sent 
to the receiving node. Its exact content is discussed later 
in the application 
note during the discussion of the 


iRMX 80 message extensions. 


A checksum is included to guarantee the integrity of the 
transmitted 
message. 
This 
field 
contains 
the 
8-bit 


modulo 256 sum of all transmitted 
ASCII characters, 


beginning with the line feed and continuing through the 
last character of the data field. It is used to compare a 
calculated checksum of received characters 
with that 


transmitted by the sending node. If these two numbers 
are in agreement, the message is considered to be valid 
and can be used by the receiving node's application soft- 
ware. 


The final field is the end of message character. A car- 
riage return is used and provides a unique indicator of 
the end of a message packet. 


The implementation 
of these communication 
concepts 


into a functioning software package is illustrated later 
during the discussion of the layering of the multipro- 
cessing communications 
package. 


Multitasking 
Message Concepts 


The design of systems which involve distributed 
pro- 


cessors strongly suggests that a multitasking 
environ- 
ment is also present. The ability to segregate an applica- 
tion into tasks allows a considerable simplification 
of 


the design and implementation 
process. In reality, few 


tasks represent 
completely 
isolated 
functions. 
Some 


degree of communications is required between the tasks. 
This may range from a simple synchronization 
of tasks 


to a data transfer. 
Real-time executives simplify these 


processes for the system designer. 
Intel's 
iRMX 80 
nucleus is an excellent example of such an executive. It 
provides low overhead, small physical size, and operates 
on almost all 8-bit Intel single board computers. 
The 


product has been thoroughly covered in several applica- 
tion notes and it is therefore not necessary to cover it 
again in this note. However, certain features are useful 
for developing a distributed processor extension of the 
basic nucleus. 


An iRMX 80 message is analogous to a letter which is 
mailed to someone. It is sent via a mailroom or post of- 
fice (called an exchange) and is then picked up by the 
receiving party. Each part of the iRMX implementation 
can be thought of in this manner. When a serial com- 
munications 
link is used between the processors, 
the 
analogy translates to that of sending a mailgram. The 
following short discussion deals with the structure and 
mechanism for sending messages between tasks which 
reside on different single board computers. For clarity, 
the mail analogy is used. 


There are several distinct parts of a message. Each has a 
function 
and a format within the message structure. 


Before a message can be generated, a medium must be 
procured to contain that message. In terms of a large 
office, this medium is paper; in the multitasking system, 
it is a block of RAM. In order to maintain a continuing 
supply of memory, the iRMX executive provides the 


user with what is known as a free space manager. The 
purpose of the free space manager is to recycle memory 
blocks so that they can be again used for generation of 
additional messages. This service is called each time the 
sending task requires to generate a message. When the 
communication programs have successfully transmitted 
the message to the target node, the memory block is 
again returned to the free space memory pool. As the 
target node receives the message it must obtain a block 
of memory from its free space manager to store the in- 
formation until it can be processed by the target task. 
The target task returns the block to the pool when it has 
taken the appropriate 
actions. 


As with any type of message, the individual to whom the 
message is to be delivered must be provided. Because the 
iRMX 80 nucleus is designed to be used by multiple 
tasks on the same processor, the target address mechan- 
ism is not included in the message header itself; instead, 
the target is specified in the call to the iRMX procedure 
as a parameter 
list component. 
When the target ex- 


change address is not known, which happens when mul- 
tiprocessor 
applications 
are created, it is necessary to 


create an extension to the executive which allows the 
assignment of a target exchange name to each message. 
Fortunately, 
this is relatively easy to create. 


iRMX 80™ Named Exchange Extension 


The iRMX 80 nucleus uses a small block of RAM mem- 
ory to store data regarding the characteristics and status 
of each exchange. This storage area normally occupies 
10 bytes of memory. Its layout is shown in Figure 16. 
Except to note that a unique identification field does not 
exist which sets each exchange descriptor 
apart, 
it is 


beyond the scope of this application note to dwell on the 
meanings of the fields. However, a method must be cre- 
ated which allows the extension of the field to include an 
identification which is unique to that descriptor. 
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Figure 16. 
Exchange 
Descriptor 


If one is not to rewrite the nucleus, the format of the ex- 
change descriptor must not be changed and the identifi- 
cation field should be added as additional bytes of the 
memory block. Two features of the iRMX 80 nucleus 
make the direct implementation of this concept impossi- 
ble. First, a special exchange descriptor already exists 


within the standard real-time executive. This is the inter- 
rupt exchange which adds 5 bytes to the nucleus for use 
as an interrupt message. Second, if an additional exten- 
sion were to be added, all exchanges would have to be 
created as interrupt exchanges so that common software 
could be used. While this would not in itself be prohibi- 
tive, the interactive 
configurator 
(ICU 80) does not 


allow addition of fields to either the standard or to the 
interrupt 
exchange descriptor. 
Another 
method is re- 


quired to add the extension. 


Fortunately, 
another 
method 
exists to create an ex- 


change. The nucleus operation, 
RQCXCH, 
creates an 


exchange at an address which is specified by a parameter 
of the call instruction. 
If user software is created to 


build the named exchanges, a name can be prefixed to 
each desired name exchange. 


In the standard iRMX 80 nucleus six characters are al- 
lowed to name each task. A logical extension of this 
concept provides a six-character name for each named 
exchange. The exchange descriptor is thus extended by 
inserting 6 bytes before the basic format. In realty, this 
is not sufficient because named exchanges are to be 
created dynamically. The memory blocks representing 
the set of named exchanges to not necessarily constitute 
a contiguous block of RAM. This leads to the creation 
of an additional word of memory to carry a pointer to 
the next named exchange field. A value of zero in this 
field indicates that no additional named exchanges exist. 
If a non-zero value is placed into the field, it is a pointer 
to the next named exchange. Figure 17 illustrates the 
structure of the named exchange fields. 
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The creation of the software to support the named ex- 
change extension is rather straightforward. 
Two func- 


tions are required; 
one which creates the named ex- 


changes, and a second which will return the address of 
an exchange which matches a given name. A complete 
listing of the software generated to perform these func- 
tions is shown in Appendix A. The services of the free 
space manager are used to allocate the memory seg- 
ments which are used for the exchange descriptors. A 


quick examination of the program techniques provides 
some insight into the operations 
involved in creating 


extensions to the standard nucleus. 


Examination of the listing at line 55 shows that a proce- 
dure is used to allow user code to determine the absolute 
address of the iRMX exchange descriptor field from the 
named exchange lists. This address can in turn be used 
with either the RQWAIT or the RQSEND instruction in 
the' user's code. If no corresponding 
name is found in 


the table, a value of zero is returned by the prbcedure. 
An address parameter is passed in the user call to the 
FIND$EXCH 
subroutine 
which points to the 6 bytes 


containing the ASCII name of the referenced exchange. 


An internal address value, identified as FIRST$PTR, 
contains the address of the first named exchange de- 
scriptor. A simple DO loop sequence is used to locate a 
matching name in the table lists. Either a zero or the 
location of an actual lO-byte exchange descriptor within 
the extended memory block is returned .. 


A task is used to provide the system capability of build- 
ing named exchanges. A task, rather than a procedure, 
is included because a task allows the initialization 
of 


system pointers such as FIRST$PTR. 
The named ex~ 
change building 
task" CREATE$COM, 
waits at its 


input exchange, COM$CREATE$EXCH 
until a request 


for creation of a named exchange is received from a user 
task. The listing for this task is found in Appendix A, 
beginning on line 78. 


When a message is received, the task obtains a 20-byte 
block of memory from the free space manager. It then 
moves the ASCII name from the requesting message 
into the appropriate 
fields and uses the iRMX primitive 


call, RQCXCH, to create an exchange descriptor within 
the memory block. The pointer (i~ld of the last named 
exchange is updated to point to the new memory field 
and the pointer field of the newly created named ex- 
change is set to zero. 


Finally, the address of the actual exchange descriptor is 
returned 
to the requesting 
program 
as an updated 


parameter of the request message. 


The creation of named exchanges greatly enhances the 
capabilities of systems designed around the iRMX 80 
nucleus. This extension allows the generation of distrib- 
uted systems in which tasks may communicate with each 
other regardless of their geographical locations so long 
as some type of link exists. 


Generation 
of Multiprocessing 
Serial 


Communications 
Link 


The creation of software for a serial communications 
link provides the capability of allowing true multitask- 
ing, multiprocessor capabilities. The need for two types 
of communications packages, a slave aJ;1da master, indi- 
cates that two separate tasks are required. Acompre- 


hensive examination 
of the communication 
require- 


ments indicates that the system can be generated in three 
layers. Figure 18 shows the layer relationships. The first 
is defined as the protocol 
and 'consists of that code 


which is required to implement the algorithms for either 
the slave or the master network nodes. The second level 
is known as the link level and contains that cOde which 
is used to support common operations such as message 
generation and data queue handling. The third provides 
a specialized interface to the physical hardware which is 
being used to generate the communications 
link. This 


level, called the physical level, is unique to each con- 
figuration. 


Figure 18. 
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Two protocol 
level communications 
packages are in- 


cluded in this application 
note. One implements 
the 


master protocol and is reproduced in Appendix B. The 
second, the slave protocol, is found in Appendix C. 


No attempt is made tb detail the operations which are 
involved in the task generation. The code is commented 
and is readily followed by the reader who has an under- 
standing 
of 
PL/M 
programming 
techniques. 
Some 


facits relating to the implementation 
of the packages as 


iRMX 80 tasks are in order. 


The master communications package is designed to use 
a USART device which is configured to provide inter- 
rupts at level 7 each time a character is received. A phys- 
ical level interrupt handler supports the receipt of each 
individual character, and, when an end of message char- 
acter (carriage r~turn) is received, places an interrupt 
message into the interrupt' exchange, RQL7EX. At this 
point (Appendix B, line 244), the master protocol han- 
dier can begin processing the received message. Because 
the task is associated with interrupt level 7, a task prior- 
ity in the range between 113 and 128 must be assigned to 
the task. The example used in this application note uses 
a priority of 113. 


inter 


In a similar manner, the slave communications task uses 
interrupt level 6 to receive messages (Appendix C, line 
130). Its priority must lie in the range between 97 and 
112. 


The link level communications package provides a com- 
mon set of procedures 
which can be used to support 
both the protocol and the physical layers. Listings of 
these support programs are found in Appendix D. The 
programs which make up the package are defined in the 
following discussion. 


Several procedures support the maintenance of the data 
queues. 
These are CQ$Q$INIT, 
CQ$NEXT$TAKE, 
and CQ$NEXT$GIVE. 
The first, CQ$Q$INIT, is used 


to clear space for a data queue. It sets up the length 
parameter and the give and take pointers to their initial 
values. 


Data is placed onto the queue by calling the procedure, 
CQ$NEXT$GIVE, 
and including the desired data in the 


paramter list. Conversely, CQ$NEXT$T AKE is used to 
take data from the queue. Both maintain 
the queue 


pointers as data is inserted or removed. For further in- 
formation about data queues, the reader should refer to 
AP-52, Using the iSBC 544™ Intelligent Communica- 
tions Controller. This document contains an extensive 
discussion on the subject of data queues. 


Two procedures deal with the transformation 
of data 


between printable ASCII and the internal binary for- 
mat. CQ$ASC$HEX transfers data from the data queue 
into a working buffer. 
In the process, it converts the 


format from ASCII into a hex representation usable by 
the target task. 
Likewise, CQ$HEX$ASC 
is used to 


transform data in a user buffer into a transmittable for- 
mat. In both cases, appropriate 
start and stop charac- 


ters are added or deleted as necessary to create the cor- 
rect format. 


One procedure deals with computing the checksum of a 
message which is in ASCII 
format. 
This procedure, 
CQ$CHECKSUM, 
returns 
a zero if the 
checksum 


agrees with that in the message. If an error is indicated, 
a value of - I (OFF hex) is returned. 


Finally, two procedures support the generation of mes- 
sage packets. One, CQ$GEN$RDY, 
is used to build a 


"ready" 
message by creating the appropriate 
data into 


the fields. The second, CQ$GEN$MSG, 
generates a 


data message containing an iRMX 80 message to be sent 
to an exchange on another processor board. 


PHYSICAL 
LEVEL COMMUNICATIONS 
PACKAGE 


The physical level communications 
package provides 


the customization 
for the unique configuration 
of host 


processor and USART. Four procedures 
must be in- 


cluded with this level. These are: 


• 
CQSINIT 
- 
This public 
procedure 
contains 
all 


operations necessary to initialize the timers, counters 
and USARTs associated with the communications 
code. In addition, 
this procedure defines the inter- 


rupt service routines for the USART and enables the 
corresponding interrupt levels. 


• 
CQSSTARTSMSG 
- 
A public procedure 
which 


places the USART into a mode in which the transmit- 
ter is enabled. The execution of this procedure should 
result in an interrupt being generated by the USART 
transmitter ready line. 


• 
CQMIVT 
- 
This is an interrupt service routine asso- 


ciated with the USART receiver ready line. It is en- 
tered each time that a character has been received by 
the communication node. In the case of a slave node, 
this procedure 
is known as CQSIVT. The name is 


unimportant 
because the location of the routine is 


passed to the iRMX 80 nucleus at initialization by the 
CQ$INIT program. 
When a,carriage return (end of 


message) is encountered, 
a message is passed'to 
the 


protocol level task by passing a message to the inter- 
rupt exchange, RQL6EX, using the iRMX primitive, 
RQISND. 


• 
SENDSCHAR 
- 
Like the CQMIT routine, this is 


an interrupt 
handler procedure. 
It is entered each 


time the USART signals that it is ready to transmit a 
character. A new character is obtained from the data 
queue and it is transmitted to the receiving node. If 
the character is the 'end of message, flags are set and 
the USART transmitter is disabled. 


The listing of a sample physical driver is provided in Ap- 
pendix E. This driver illustrates the use of the iSBX 351 
Serial MUL TIMODULE Board placed into a socket of 
an iSBC 80124 Single Board Computer. 


The example from the application implements a multi- 
drop slave node. The enabling of the tri-state drivers is 
accomplished in line 138 by sending the USART a com- 
mand of 025H. When the message has been sent, the 
driver is again placed into a high impedance mode by 
sending a command 
of 026H (line 121). These com- 


mands control the driver by toggling the DTR or Data 
Terminal Ready lines of the 8251A USART device. 


The alarm and security system previously discussed pro- 
vides a perfect environment in which to use the concepts 
developed in this application note. 


To verify the functionality of the communications pack- 
age, the transmissions 
between a master and a slave 
were monitored using a CRT terminal. The terminal was 


connected to one of the RS232 serial paths using a tee 
network. This tee network is shown in Figure 19. Sey- 
eral scenarios were set up to test the effective~ess of the 
communications 
protocol. The results of some of these 


tests are recorded in the following discussion. 


A test of normal communications 
was performed 
in 


which one message is passed between the master and the 
slave. A short time later, a message is passed to the 
master from the slave. The CRT display for this action 
displayed as: 


(line I) 
033ססoo 
(line 2) 
00300FD 


(line 3) 
03200091230900BFOOOOOOOO9F 


(line 4) 
00310FE 
(line 5) 
0331001 
(line 6) 
002108247090087000000008A 


(line 7) 
0331102 
(line 8) 
00311FF 


Line 1 is a "ready" 
(character 
3) .message from the 
master node to a slave addressed 03 hex (characters 
I 


and 2). No messages have been sent in either direction at 
the time this message was generated. On line 2, the slave 
has responded indicating that it is present and ready to 
receive messages. It also has not transmitted 
any mes- 


sages to the master nor has it received any. 


The master node sends the slave a message 
011 line 3. 
Note that the message count field (characters 4 and 5) is 
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not changed until after the message has been trans- 
mitted. The message sent is a type BF and has a total 
length of 9 bytes. On line 4, the slave acknowledges that 
is has received one message and has sent none. 


Lines 5, 6, and 7 illustrate a sequence in which the slave 
sends a message to the master node. Prior to the mes- 
sage being sent, the message count field shows that one 
message has been received. After receiving 'the message, 
the master node increments its received counter. 


Tests with the alarm and security system verify that the 
communication module functions correctly. Data integ- 
rity is maintained even through intentional disruption of 
the electrical link. Both the RS232 and RS422 communi- 
cation paths function as designed. 


A detailed discussion of this application 
and of the 


multitasking capabilities of the iRMX 80 nucleus can be 
found in AP-112, Simplifying 
Complex Designs Using 


The iRMX 80™ Executive. 


This application note illustrates the ease with which a 
user can add extensions to the iRMX 80 executive to 
support 
a distributed 
multiprocessing 
application. 
In 


addition, 
the user of standard 
"off 
the shelf" 
single 


board computers 
and expansion modules to create a 


hardware solution is explained. 


The ability to break applications into small tasks, either 
functionally or geographically, aids the system designer 
by allowing his concentration 
on each task. A message 


transfer capability allows these tasks to again be tied 
together to form a complete solution to the application. 
Where the tasks reside on the same single board com- 
puter, the standard iRMX nucleus provides this ability. 
When different host boards are used, extensions to the 
nucleus allow the same functions to be performed. Both 
multiple processors on the same MULTIBUS chassis 
(refer to AP-88 and AP-1I2) and in different chassis 
using the serial links described in this application note 
can be supported with extensions to the nucleus. 


Many concepts are used to create serial communication 
networks. 
Intel's 
single 
board 
computer 
products 
simplify the design process. 
Among 
these products, 


several stand out in this application. 
For example: 


• 
iRMX 80™ Executive 
- 
This outstanding product 


simplifies the design of multitasking systems and pro- 
vides a foundation 
for the implementation 
of exten- 


sions to create many varied configurations. 
Such 


things as task synchronization, 
interrupt 
handling, 
and message transfers allow multitasking. 
The free 


space manager allocates RAM and is an integral part 
of the serial communicaitons link software. The ter- 
minal handler and the disk operating system simplify 
the software design by providing ready to use I/O 
drives which can be accessed by the user. 


• 
ISBC 
80/10BTM Single 
Board Computer 
- 
This 


microcomputer 
allows a low cost solution to many 
small to medium applications. The ability to operate 
the board in an iRMX 80 environment enhances its 
capabilities by allowing it to multi process. Its on- 
board serial communications link allows it to be used 
as a slave node in either EIA or current loop com- 
munications networks. The iSBX MULTIMODULE 
connector further enhances its capabilities by allow- 
ing customization 
of I/O to meet a wide variety of 


user applications. 


• 
iSBC 
544™ Intelligent 
Communications 
Board 


- 
The use of this board allows much of the protocol 


and physical drivers to be off-loaded 
from the host 


processor. The board provides an ideal master com- 
municatons node for star type networks. By placing 
the handshaking 
operations 
on the communication 


board, 
the 
host 
is free to 
perform 
application- 


oriented functions with a much higher throughput 
rate. 


• 
iSBC 
80/24™ 
Single 
Board 
Computer 
- 
This 


powerful 8085A-2 based microcomputer 
board pro- 
vides the capability to implement most of the system 
functions without the need to expand to additional 
memory or I/O expansion MULTIBUS boards. 
It 


fully supports the iRMX 80 executive. Its ability to 
act as a full bus master allows even greater flexibility 
through the implementation 
of MULTIBUS multi- 


processor 
solutions. 
The two iSBX MUL TIMOD- 


ULE expansion 
connectors 
provide the user with 


considerable flexibility in the design of his system. 
The use of one of these sockets as a carrier for the 
serial 
communications 
MUL TIMODULE 
board 


makes a multidrop serial communications 
link prac- 


tical. 


• 
ISBX 351™ Serial 
MULTIMODULE 
Board - 
The 


implementation 
of multidrop 
communications 
re- 


quires the use of an electrical interface which sup- 
ports more than one communicaitons 
node to share 


the link. The use of the RS422 operating mode of the 
board easily implements this feature. A well-defined 
hardware protocol also assists in the implementation 
of a serial multidrop communications 
link. Up to I I 
slave nodes can be designed into a system using this 
powerful board. In addition, the iSBX 351 board can 
function in either the RS232C or the EIA mode for 
linking into terminals or for creating a point to point 
network. 


The assistance of Judy McMillan in the implementation 
and testing of the security system and its communica- 
tion links is greatly appreciated. 


inter 
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Stitle('RMX/80 
EXTENSION 
TO NAME 
EXCHANGES, 
VERSION 
1.3') 
createScomSexch: 
do; 
/********************************************************* 
CREAT$EXCHANGE 
creates 
a list 
of exchanges 
associating 


the 
name 
of an exchange 
with 
its location, 
for 
the purpose 


of 
other 
tasks 
wishing 
to find 
the 
location 
of 
an exchange. 


FIND$EXCHANGE, 
when 
given 
the name 
of an exchange, 
polls 
down 
the 
list 
and, 
when 
it finds 
a match, 
returns 
the 
address 
to the 
requesting 
task. 
/********************************************************* 
$nolist 


declare 
CO~$CREATESEXCH 
exchange$cescriptor 
public; 
declare 
CREATE$EXCH 
exchange$descriptor 
public; 


declare 
first$ptr 
declare 
last$ptr 
declare 
msg$ptr 
declare 
exch$ptr 
declare 
n 


address; 
address; 
address; 
address; 
byte; 


declare 
request 
based 
msg$ptr 
structure( 
msgShdr, 
exch$name(6) 
byte); 


declare 
fs$req 
structure( 
msgShdr, 
msg$length 
address); 


declare 
exch 
based 
exch$ptr 
structure( 
name(6) 
byte, 
exchange(10) 
byte, 
link 
address); 


declare 
lastSexch 
based 
last$ptr 
structure( 
name(6) 
byte, 
exchange(l~) 
byte, 
link 
address); 


declare 
response 
based 
msg$ptr 
structure 
( 
msg$hdr, 
exchange 
address 
); 


NAMEX: 
Procedure(exptr) 
address 
public; 
~eclare 
addr 
address; 
ceclare 
exptr 
address; 
declare 
(ex based 
exptr) 
(6) byte; 


/* declare 
the 
returning 
message 
with 
the address 
*/ 


inter 


46 
2 


47 
2 


48 
2 


4S 
2 


5C 
;:> 


51 
;:> 


52 
;:> 


5~ 
2 
57 
2 
51' 
2 


5~ 
2 


(;1 
2 


1)2 
3 
r.;:: 
3 


(\tl 
<1 


(-.5 
4 


r,~ 
5 


f~cl~rr 
retS~sg 
h?sed 
addr 
structure(msghdr, 
exchSpdr 
2d~ress); 


~ec12re 
reg 
structure(msgShdr, 
ne.me(n) 
byte); 


1* 
cre~te 
2n 
exch2nge 
to 
comnunic~te 
with 
tI'e corm 
cre?te 
f'XChClngf'*1 


decl?re 
fsx 
exch2ngedescriptor; 
c211· rqcxcr(.fsx); 


reo.length 
= 
]5; 
cell 
nove((" 
.ex, 
.reg.name); 
req.type 
= 
21.0.; 
req.response$exchange 
= 
.fsx; 
cell 
rqsend(.co~create$f'xch, 
.reg); 


~d0r 
rqw?it(.fsx, 
0); 
e0er 
= 
ret$nsg.exchSadr; 


return (add r) ; 


end; 


FINDSEXCH: 
procedure 
(n?np$ptr) 
address 
public; 


I****~*******************+***************************** 
Tri ; ~ rocf'(~ure fin(~s the 
exch2nge 
heving 
e 
neme 
specified 
by 
the 
passed 
paremeter 
pointer. 
If 
'" metch 
is 
foune 
the 
exchange 
pcdress 
is 
returned. 
If no 
match 
is 
found, 
'" 


zero 
is 
returned. 
********************************************************1 


declClre 
n2me$ptr 
ecdress; 
declare 
m?tch 
byte; 


cecl2re 
(name 
bi'lsec1nameSptr) 
(G) 
byte; 


1* 
test 
for 
no 
exchanges 
*1 
if 
firstSptr 
= r 
then 
return 
0; 


1* 
test 
for", 
npme 
m~tch 
*1 


else 
co; 
cxch$ptr 
= 
firstSptr; 
co 
Ylh i leI 
; 
I'1Atch= 
0ffh; 
('0 
n = r 
to 
5; 
if 
nAme(n) 
<> 
exch.n2ne(n) 


in1:el 


r-;f: 
:; 
(,C 
11 
71 
4 
73 
" 
74 
11 
75 
3 
7(, 
:> 
77 
2 


7f'. 


79 
2 
8e 
2 


81 
2 
82 
2 


83 
2 


84 
3 


1>.5 
3 
8(, 
3 


e7 
3 
88 
3 
89 
3 
9C 
3 
91 
3 


92 
3 


end; 
if 
M?tch 
tren 
return 
.exch.exchengp; 


if 
exch.link 
= 
0 then 
return 
r; 
exchSpt 
r = 
exch.] ink; 
end; 
enc; 
return 
0.; 


enc; 


CREl'TF:SCOM: 
procec'ure 
puhJic; 


/****************~***********************************~**** 
This 
proceeure 
creates 
exchange 
extensions 
wren 
asked 
to 
do 
so 
by 
? 
task 
that 
wants 
its 
exchange 
mac.e completely 


accessihle. 
It 
saves 
the 
naMe 
of 
the 
exchange 
then 


creates 
an 
exchange 
to 
save 
its 
peeress. 
It 
may 
be 
urc.ated 
at 
?ny 
time. 
**********************************************************/ 


/* 
initiclize 
exchanges 
*/ 
call 
rqcxch(.com~r.reat~$exch); 
cnll 
rqcxct (.create~exch) 
; 


/* initialize 
pointers 
*/ 
Jast~ptr 
= 
0; 
first$ptr 
= 
0; 


/* get 
a 
request 
for 
crention 
of 
an 
exchange 
*/ 


msgSptr 
= 
rowait(.comScreateSexcr., 
r); 


/* get 
some 
memory 
for 
the 
excr,ange 
*/ 


fs$reo.length 
= 
11; 
fsSreq.type 
5; 
fs~req.response$exch?nge 
= 
.crepte5exch; 


fsSreq.msgSlength 
= 
20; 
cal] 
rosenr(.rqfsax, 
.fs$req); 
exchSptr 
rowait(.cre?te~exch, 
r); 
exchSptr 
= 
fsSreq.msgSlength; 


/* store 
name 
in 
the 
exchange 
structure 
*/ 


c?ll 
mover 
(;, .request.exch~name(0), 
.exch.nnMe((')) 
; 


/* create 
en 
exchenge 
*/ 
cn]l 
rqcxch(.exch.exchange(r.)); 


if 
lestSptr 
> 
0 
then 
co; 
lastSexch.link 


inter 


97 
11 


9F 
t. 


9S' 
<1 


Irr 
3 
leI 
4 
H2 
~ 
H3 
4 
Hi] 
4 


H:· 
3 
1('5 
3 


IC7 
3 
108 
2 
lr9 
] 


I?st$ptr 
= 
exchSptri 
exc!'>.] ink 
= 
ri 
endi 
eIsf' COi 
f'xch.link 
= 
r'i 
first$ptr 
= 
exch$ptri 
lrstSptr 
= 
exch$ptri 


/* return 
the 
exchange 
pointer 
*/ 
r('sponse.exchange 
= 
.exch.exchan~ei 
call 
rqsenc(reauest.responseSexchcnge, 
m~a$ptr); 


('nc' ; 
enc; 


~ODULE 
rNFOR~ATrON: 


CODE 
}IRE" 
SIZE 


V}lRIAPLE 
lREA 
EIZr 


~"XI~UM 
ST"CK 
SIZE 


244 
LINES 
RE,a.[' 
r. 
PRCGR,a~ 
ERROR(S) 


(nD:?H 
r:r4PlJ 
00r4H 


4f17D 
72D 
4D 


Stitlr('~~ster 
COMmuni~etions 
Protocol 
rriver, 
Version 
p.1 ') 
1 
~~~T~R~DRJVFR: 
~o; 


/'" 
T~€ 
tesk 
conteinef 
in 
this 
listing 
supports 
the 
M?ster 


cornnunicetions 
protocol 
for 
extabJishing 
network 
canmun- 


iC2tions. 


The 
tC'sk must 
be 
confi9Llre(1 usinq 
the 
rcu/pC' 
2S 
fol1o\o's: 


TrSK 
N~~P.: MrSTER 
T,aSK F.l"TRYPOrt!T: ~'LIN¥ 
T~SK 
PRIORITY: 
1J3 
T(I~K STICK 
LENCTH: 
Irr 


EXCH~NGE: 
POL7FX 
SCOPF.: 
FXTERl\?,L 
INTf:RRLTPT: Yf:S 
EXCHI',NGF.:TI~EX 
SCOPE: 
PUBLIC 
INTERRUPT: 
NO 


LINK: 
:Fn:CCCOr>~.LIB 
LINK: 
:Fn:CCR~LV.LIP 


Tasks 
~psiring 
to 
senr 
? ~pss?ge 
to 
? nace 
shoul~ 


sen~ 
e 
messaGe 
to 
the 
pxcranqe 
r~~IEX(no~e). 


*/ 
$ir._lufe 
(:fr:exch.elt) 


cr.~···F. EXCP~NCE~DFfCRIPT0R 
LITERALLY 
'STRUCTURE 
( 


MSG~HF.AD 
ADDRESS, 


~SG~TI'IL 
ADDPEfS, 


TI'SK~HE!,D ,aDDRE~S, 
TAPKST1IL 
ADCRESS, 


NEXTSEXCP 
lCDRESS) 
'; 


~include 
(:fr:ie~.elt) 
DECLARE 
INTSEXCH~NGF.~DFSCRIPTOR 
LITERALLY 
'STRUCTURf: 
( 
MF.SSACE$P.EAD 
l'DDRESS, 


MESSl'CE~TAIL 
ADDRF.SS, 
TASKSHE~D 
I'DDPESS, 


T~SK$TArL 
I'DrRF.PS, 
EYCHI'NGE~LINK 
ADDRESS, 
LINK 
,aDDRFSS, 
. 


LE!,-IGTHADDRESS, 
TYPE 
PYTE)'; 


$include 
(:fr:~sq.plt) 


DECLARP. 
MSG$HDR 
LITERALLY 
, 


inter 


1 
1 
= 


1 
= 
1 


LINK 
ADDRESS, 


LENGTH 
ADDRESS, 


TYPE 
BYTE, 


HOME$EXCHANGE 
ADDRESS, 


RESPONSE$EXCHANGE 
ADDRESS'; 


DECLARE 
~SG$DESCRIPTOR 
LITERALLY 
'STRUCTURE ( 


MSG$HDR, 
REMAINDER(I) 
BYTE) '; 


$include 
(:fC:common.elt) 


DECLARE 
TRUE 
LITERALLY 
'0FFH'; 


DECLARi 
FALSE 
LITERALLY 
'COH'; 


DECLARE 
BOOLEAN 
LITERALLY 
'BYTE': 


DECLARE 
FOREVER 
LITERALLY 
'WHILE 
1': 


$include 
(:f0:synch.ext) 


RQSEND: 


PROCEDURE 
(EXCHANGE$POINTER,MESSAGE$POINTER) 
EXTERNAL: 
DECLARE 
(EXCHANGE$POINTER,~ESSAGE$POINTER) 
ADDRESS: 


RQWAIT: 
PROCEDURE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS 
EXTERNAL; 
DECLARE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS: 


RQACPT: 
PROCEDURE 
(EXCHANGE$POINTER) 
ADDRESS 
EXTERNAL; 
DECLARE 
EXCHANGE$POINTER 
ADDRESS: 


RQISND: 
PROCEDURE 
(IED$PTR) 
EXTERNAL: 
DECLARE 
IED$PTR 
ADDRESS; 


END 
RQISND; 


$inclu.lp (:f0 :intrpt.ext) 
RQENDI: 
PROCEDURE 
EXTERNAL; 


RQELVL: 


PROCEDURE 
(LEVEL) 
EXTERNAL: 


DECLARE 
LEVEL 
BYTE: 


RQDLVL: 
PROCEDURE 
(LEVEL) 
EXTERNAL: 


DECLARE 
LEVEL 
BYTE: 


inter 
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," 
..,.\(; 
,' 
2 
_ .1 
32 
2 


33 
2 


3" 
1 


35 
2 
]~ 
2 


37 
'2 


38 
1 
3~' 
1 


4r 
1 


-11 
1 


44 
1 


45 
2 


-:r, 
2 


47 
1 


LIB 
2 


49 
2 


Sf] 
1 


51 
? 
52 
2 


RQSETV: 
PROCEDURE 
(PROe,LEVEL) 
FXTERN~L; 
rEeLl~E 
PRCC 
lDDRESS; 
DECLlRE 
LEVEL 
BYTE; 


ROSETP: 
PROCF-DURE 
(PRCe,LEVEL) 
EXTERNAL; 
DECLARE 
PRoe 
ADDRESS; 
DECLARE 
LEVEL 
BYTE; 


EtJD RQSFTP; 


$incluc~ 
(:fr:fsmgr.ext) 
DECLARE 
RQFF~X 
EXCHANGESDESCRIPTOR 
EXTERNAL;" 


DECLJlRE 
RQFSRX· EXCllJ'NGESDESCRIPTOR 
EXTF.RNAL; 


DECLARE 
RQFREE 
EXCHANGE$PESCRIPTOR 
EXTERNAL; 
Sincluce 
(:fl:m?smsg.elt) 
cp.clere 
rnsgSformct 
literally 
'structure 
( 


trgt 
byte, 
cr.mcl 
byte, 
seq$l? 
byte, 
seq$n? 
byte, 
t.ext(250) 
byte) 
'; 


declare 
queueSform?t 
literally 
'structure 
( 
endSptr 
byte, 
giveSptr 
byte, 
takeSptr 
byte, 
c1atClSbyte(254) 
byte)'; 


declare 
parSforMat 
literally 
'structure 
( 


na 
byte, 
la 
byte, 
run 
by"te, 
stop 
byte, 
queSpt 
byte) 
,; 
Sinclucl€ 
(:fr:objrnan.ext.) 


RQCTSK: " 


PRCCEDURE 
(STATIC$PTR) 
EXTFRNAL; 
DECLARE 
STJlTIC$PTR 
fDrRESS; 


RCCXCH: 
PROCEDURE 
(EXCHANGE$PTR) 
EXTERNAL; 
DECLARE 
EXCHANGE$PTR 
ADDRESS; 


END 
RQCXCH; 
$include 
(:fl:coMcom.ext) 
~ 


CQSNEXTSGIVE: 
Procedure 
(q$ptr,givetbyte) 
byte 
extern8l; 


Declare 
qSptr 
adclress; 
Declare 
giveSbyte 
byte; 
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= 


511 
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= 


55 
2 
= 
51' 
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= 
57 
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= 
= 


58 
2 
= 


5~ 
? 
= 
r.;r 
1 
= 
= 


nl 
2 
= 


r.;2 
2 
= 


"3 
'2 
= 


r.;<1 
] 
= 
= 


I1S 
2 
- , 


r.;6 
2 
= 
fS7 
1 
= 
= 
Foe 
2 


(,9 
2 


70 
1 
= 
= 
71 
2 
= 


72 
7- 
= 
7: 


=' 
= 
7/J 
1 
= 
= 
75 
? 
= 
7f:. 
2 
= 


77 
7- 
= 


7P 
1 
= 
= 
7C; 
2 
= 


8C' 
2 
= 
PI 
2 
= 


P2 
1 
= 
= 


83 
2 
= 
ell 
? 
= 
P5 
2 
= 


86 
1 


P7 
? 
Be 
1 


89 
2 
90 
2 
91 
1 


n 
2 
~3 
7. 


en~ cq~next~givp.; 


CQtT.aKE$TF~T: 
Procedure -(q~ptr) byt.e eyte.rn?l; 


D~cl?re 
c.~ptr r.ocress; 


end cq!tr.ke~tcst; 


CO$~'F.XT$T"KE : 


Procedure 
(q$ptr) tyte 
externel; 


recl?re 
q~ptr 
nddress; 


end cq~next$toke; 


rQ~0SINIT: 


Procedure 
(q$ptr,q~size) 
extE'rn.•.• 
l; 


recl?re 
q$ptr 
address; 


Decl .•.• 
re q~size 
byte; 


cnc cq$qSinit; 


CQt ".scsm:x: 


Procedure 
(q$ptr,Msg~ptr) 
extern?l; 


Declare 
(qSptr,msgSptr) 
.•.• 
ddress; 


end cqS?sc$hex; 


CCSCfJECKSU'" 
: 
Procedure 
(qSptr) byte .extern~l; 


~ecl?re 
qSptr 
.•.• 
ddress; 


enc cq$checksum; 


CQ$HF.XS}\~C: 


Procedure 
(qSptr,rpxSbyte) 
pxtern?l; 


r.eclare q$ptr 
?cdress; 


Declare 
hexSbyte 
byte; 


enc cq~rexSpsc; 


CQt",SGSOUT: 
. 


Procedure 
(msg$size,aSptr,porSptr,msg!ptr) 
extern .•.• 
l; 


Declare 
rnsgSsize byte; 


Decl .•.• 
re 
(q$ptr,par$ptr,MsgSptr) 
r.dcress; 


enr'!cq$msgSout; 


CQSGEN$RDY: 


Proce~ure 
(trget,rsgSptr,q~ptr,p~rSptr) 
external; 


Decl .•.• 
re trget 
byte; 


Declere 
(msg$ptr,qSptr,perSptr) 
.•.• 
~cress; 
enc coSCjenSrdy; 


CeSC Et-'S""SG: 
Procedure 
(rnsgSpointer,t.rget,MsgSptr,qSptr, 


ppr!ptr,s?veSflg) 
extern?l; 


reclC're (trget,sc!lve!flg)bytE'; 
Declace 
(msgSpointer,MsgSptr,qSptr,par!ptr) 
redress; 


end co$genSmsg; 


USRINT: 
Procedure 
external; 


pncl usrint; 


FTNDSEXCH: 
Procedure(npme!ptr) 
?ddress 
extern?l; 


decl .•.• 
rE'n<'me$ptr rcdress; 


enc 
findSexch; 


~I}\M FoX: 
Procecure(exptr) 
?ddress 
extern~l; 


~eclare 
exptr 
~~~ress; 


end nPMex; 


inter 


lrl 
lr.2 
1('3 
lC~ 
](15 


returntrel'l: 
procenure(pointer) 
external; 


declare 
pointer 
e~cress; 


end 
returnSral'l; 


Cert~in 
literals 
ere 
usee 
to 
refine 
the 
network's 


physic?l 
characteristics. 
These 
ere: 


Decl?re 
N~N0DE 
literally 
'~'; 
/* numher 
of 
nores 
*/ 


Declare 
NrD~5~RRAY 
literelly 
'5'; 


~ 
structure 
provides 
the 
rete 
0ueues 
for 
the 


transMission 
of 
oata 
to 
eecr 
noce. 
It 
is 
defined 
end 
is 
available 
as 
a 
public 


A single 
date 
queue 
is 
used 
to 
support 
the 
input 
of 
dete 
froM 
a 
nore 
since 
only 
one 
slave 
is 
given 
a 


window 
at 
e 
ti~e: 


Each 
node 
has 
an 
associeted 
set 
of 
flags 
which 


indicate 
the 
operation?l 
I'lodeof 
that 
node. 
The 


function 
of 
each 
bit 
is 
definec 
as: 
bit 
0 
- 
reouest 
synchronization 
(synchtreQuest) 


bit 
1 
request 
initializetion 
(initSrequest) 


bit 
2 
repeat 
lest 
mp.ssege 
(repeatS 
request) 


bit 
3 
bit 
4 
- 
bit 
5 - 
bit 
I'; 
- 
bit 
7 
- 
error 
fleg 
(errorSflag) 


Declare 
COC~DF(nodeSerray) 
byte 
puhlic; 


neclare 
SYNCHSREQUEST 
literally 
'r~H'; 


Ceclare 
INJTSREOUEST 
literelly 
'r2H'; 


Declare 
REPE~TSREOUEST 
literally 
'r~H'; 


Declrlre 
ERRORSFLll.C ,liter?lJy 
'PCB'; 


l 
counter 
is 
used 
to 
indic?te 
the 
number 
of 
ettempts 


to 
establish 
communications 
with 
e 
node. 
~~en 
it 
reacres 
a maxiMum 
velue, 
a 
synch 
will 
be 
sent 
to 
the 


node. 
when 
the 
maxiMum 
value 
of 
synchs 
are 
sent 
to 
a 


node 
with 
no 
effect, 
a 
reset 
will 
be 
sent 
to 
the 
node. 
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1 
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1 
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1 
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Declare 
EPRQPtCOUNT(noce~array) 
byte; 
Cecli're 
r-'l".X~COtJNT 
literi'lJy 
'5'; 
Peclere 
SYNCP~COUNT(no~et2rr~y) 
byte; 


/* 
a 
pointer 
is 
used 
to 
store 
the 
pceress 
of 
exch?nges 


usee 
hyincomminq 
messages*/ 


" 
set 
of 
exch?naes 
is 
USCG 
to 
hole 
2 
~eSS2ae 
until 
it 


h~s 
been 
?cknowled0ed 
by 
the 
sJeve. 


A 
set 
of 
exchanges 
is 
provided 
to 
accept 
~pssages 
which 


ere 
to 
be 
sent 
to 
any 
of 
the 
nodes. 


Peclere 
reqSrnsg 
structure 
msgShClr, 
msg$length 
redress 
); 
Declare 
(m,n,nodetcnt,outmo0e,r?~~size) 
byte; 


Declare 
msg$ptr 
address; 
Declare 
msg 
msgSformat; 
declere 
sterttSl4 
byt~ 
public 
et 
(?C00h); 
Declare 
data$hlock 
hased 
msgtptr 
structure 
msgShc 
r) ; 


Declare 
C0~P"P(node$erray) 
rar~form2t 
puhlic 
at 
(811r2h); 
Ceclere 
PA~S~SG 
besec 
msgSptr 
structure 
( 


msg$r-cr); 
Declare 
CQSPCTIVE$NODE 
byte 
public 
?t 
(PC0lh); 
Declare 
freSmem 
address; 
Declare 
fr€~msg 
basec 
freSmem 
structure(msg$rdr); 


The 
task 
uses 
certain 
exch2nges 
for 
internel 


cOlT1munications 


Declare 
CQMSEX 
exchenge~descriFtor; 
Declare 
RQL7EX 
intSexcr-ange$~escriptor 
pubJic; 
Spject 


/******************************************************* 


error~test 


This 
short 
proceeure 
is 
used 
to 
increment 
the 
error 


counters 
2nd 
to 
signal 
en 
initialization 
or 
synch 
comm?nd 


when 
required. 
It 
will 
order 
a 
re-transmission 
of 
the 
last 
message 
eecr- time 
an 
error 
is 
detected. 
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3 
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" 
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If 
(error~count 
(n) :=er rorS("ount (n)+1) 
> 
r.l?x~count 


then 
00; 
error$count(nJ=C; 
if 
(sync~~count(~) 
:=synchScount(r.l)+]) 
> 
n~x~count 


then 
~o; 
synchtcount 
(1:1) 
= 
0; 
cqcnc'f(n) 
cqcnrf(n) 
or 
error~fl2q 


. 
or 
initSrequest; 
enc'; 
else 
cqcr,li1f(n)=cqcmr'lf(n) 


.or 
error$fJ?g 
or 
synch~request; 


eno; 
else 
cacmcf(n) 
cqcndf(n) 
or 
repeatSreauest; 


return; 


c-' 
-rrotSt.est; 


Seject 
~LINK: 
Procedure 
puhlic; 


/* 
Init.ialize 
the 
system 
?nc' t.he t?S~ 
*/ 
Do 
n=l" to 
NSNODE; 
CQr~DF(n)=synch~request 
or 
error~fl~g; 


CQt-'P".R(n).run,CQI"PJlR(n) .stoF,cor·1p!',R(n).aueSpt=Cj 
ERRCR$Cr.UNT(n) 
=0; 
SYNCH~COUNT(n)=n; 
enc1; 


/* Initialize 
the 
noc1e pointer 
*/ 
NODESCNT=l"j 


/* 
Initialize 
the 
input 
exchanges 
*/ 
Do 
N=r. to 
nSnode; 
CeJ 1 
RQCXCH 
(.CC'I"IEX 
(n) 
); 
c211 
RQCXCH 
(.HCLD~EXrH 
(n)) 
j 
end; 


/* 
Initielize 
t.he aueues 
*/ 
call 
cqSqSinit(.cqmstq, 
25"); 
c211 
caSqSinit(.cqmsia, 
254); 


/* Crectc 
the 
nemed 
exch?nges 
,nc' give 
r?m 
to 
fsm*/ 


ci"ll 
usrint; 


/* 
init.ialize 
the 
level 
7 
interrupt 
exchange 
*/ 


call 
rqelvi (7); 


/* Begin 
main 
task 
loop 
*/ 
Vo 
fo reve r; 


/* Begin 
support 
of 
one 
nocal 
ch2nnel 
*/ 
Do 
n=] 
to 
n~noc'e; 


inter 
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4 
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4 
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Ll 
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17r 
5 
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G 


172 
G 
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5 


17t 
t 


175 
5 
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r; 


/* 
reset 
cueue 
pointers 
*/ 
r.q~sra..give~ptr, 
ca~stq.t~ket-ptr 
r; 


/* COMpute 
n00~1 
Mooe 
numher 
*/ 
If 
(coC"mdf(n) 
eno 
synct"J~request»r. 
then 
out~o~e 
= 
1; 
else 
outmoce 
= 
0; 
If 
(cq("l':lc;f(n) 
?ne' initSrequest»r: 


then 
outm00e 
= 
7; 
cq~0ctive$no~e 
= 
n; 


/* 
if 
corom f?ilurp, 
kill 
211 
messaoes 
*/ 


if 
(cqcmdf(n) 
?nc1 errorSf12g) 
> r. 
then 
do; 
00 
while 
(msgSrtr:=ro;;cpt(.C"amiex(n))) 
> 
0; 
cell 
return$r0m(~sg$ptr); 
enr; 


do 
while 
(I"sg~ptr:=ra?cpt 
(.roldSexch 
(n))) 


> r; 
cell 
rE't.urnSrC'm(msg~ptr); 
end; 
E'nc; 


/* Operate 
on 
nodal 
mooe 
*/ 
Do 
cC'se outmode; 


/* cC'se 0, 
routine 
communic~tions 
*/ 


Do; 
If 
(cqcmdf(n) 
cnr 
repeC't$request»n 


then 
~o; 


/* support 
of 
retr?nsmission 
reauest 
*/ 


cacmcf(n)=cqcmcf(n) 
one' not 
repeet~request; 


msa~ptr=ra2cpt(.t"Jole'$exch(n)); 
if 
msgSptr>r 
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/* 
retrensmit 
old 
ME'SS?ge 
*/ 


then 
('0; 
if 
camper(n) 
.n," = r 
then 
canper(n) 
.n? 
= 
15; 


else 
cqmper(n) 
.n.=o=cq~per(n) .ne 


- 
1; 


c?ll 
ca$gen~msq(msg~ptr,n,.msg, 


.cqrnstq, .cqmp~r 
(n) ,0); 


c?ll 
rqseno (.r.olc'Sexch (n) , 
msgSpt 
r) 
; 
if 
r.ompi'lr(n).n? 
= 
l5 
then 
cql"per(n) .ne = v; 


else 
cqmp.=or(n) .ne 
=camp?r 
(n) .n,:o+1; 


intJ 


IS 1 
7 
E2 
f 
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R 
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8 
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7 
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/* 
no 
old 
Mess~~e, 
senr. reedy 
*/ 


else 
<'0; 
r.1sQ.trgt=n; 
r.1sg.cr.mr:1=3; 
cell 
cqSmsgSout(0,.cqr.1stg, 
.•rqmper(n) 
,.msg); 


end; 
end; 
/* enr 
of 
retransmission 
*/ 


/* support 
of 
next 
messege 
*/ 


el Sf' 
cO,); 


/* cleAr 
role 
exch~nge 
*/ 


I'1sgSptr=rqacpt. (.hol<'Sexch 
(n)); 


if 
msgSptr>0 


then 
<'0; 


2Cl 
2 (' 2 


/* 
free 
srAce 
return 
size 
*/ 


r?msize=C?tASblock.length; 
if 
(rCll'1sizemod 
to) 
> r 


then 
rat?Shlock.length 


=d?teSblock.]ength 
+(ll-(remSsize 
l'1or:1 
4)); 


cc'l]1 RQ8n1D 
(.rqfsrx 
,r.1sgSptr); 


enc; 


2(;" 
f' 
2(:5 
P 


2('6 
7 


2(;7 
7 


2r9 
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/* test 
for? 
message 
output 
*/ 


msgSpt 
r=rqacpt 
(.cqmiex 
(n) ); 


2]] 
212 


/* when 
a 
message 
exists 
*/ 


if 
msgSptr>r 
tren 
c'o; 
if 
(ta rqetSexch: 
=ffnn$pxch(msgSptr 
+9))> 
r. 


then 
c?ll 
rqsenc'(t~rget$exch,msg$ptr); 


else 
('0; 
cell 
cqSgenSnsg(msgSrtr,n,.nsg, 
.cqmsto,.cqf'p~r(n) 
,f:); 


call 
rasenrl (.holcSexch 
(n) , 


msgSpt 
r) ; 
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/* increfse 
tre 
n~ 
fl~g 
*/ 


if 
cql'1per(n) .n~ 
15 


then 
r.qmper(n) .ne 
= r; 


else 
cOl'1per(n) .ne 
= 
comp~r(n) 
.n? 
+ 
1; 


end; 
en(~; 


/* when 
no 
message 
exists 
*/ 


else 
00; 
r.1sg.trgt=n; 
msg.crnn('=3; 


inter 
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2;Jr. 
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.1 
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4 
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c?l] 
cq~~sgtout(r,.cqnstc, 
.cq~pr r (n) ,.msn); 


C'nrJ; 


en0; 
/* enn 
of 
routine 
ness2ge 
*/ 


/* strrt 
the 
Mess2ge 
tr2ns~ission 
*/ 


startt54t" 
= n; 


/* c?se 
1, syncr 
request 
*/ 
co; 


cqmp2r(n) 
.n2,cqnpnr(n) 
.1? 


msg.trgt=n; 
MSg •cmnc1=] ; 
ci'I1 
cqtmsg$out 
(C,.cqmstq,.campar(n) 
,.(1'\sg); 


start$5.14 
= n; 


cacM0f(n)= 
cqcnrlf(n) 
ane' not 
synch$requ€st; 


/* c?se 
2, 
initialize 
request 
*/ 
do; 


cqcmrf(n)=(racmc'f(n) 
rnn 
not 
init~request) 
or 
synchSrcquest; 


cgmpC1r(n) .n?, 
cqnpar(n) 
.In 
= 
r; 


msg.trgt=n; 
msq.cnnc'=(1; 
cril 
co$nsntout 
((',.comstC', .cqMpa r (n) ,.nsa) ; 


stC1rt$5114 = 
n; 
ene'; 


/* 
wait 
for? 
response 
from 
tre 
sIr-ve */ 


msgSptr 
rqwcit(.rql~ex,25); 
start$5L14 
= r; 


/* test 
for? 
ness?ge 
or 
? 
tiMeout 
*/ 


if 
r2MSmsg.type=3 


/* support 
of 
no 
v21ie' response 
*/ 


then 
/* test 
for 
m?x 
number 
of 
errors 
to 
n00e 
*/ 


c211 
error~test; 


/* 
support 
of 
gooe 
response 
return 
*/ 


else 
00; 


if 
cqtchecksuml.cq~siq)=r. 
then 
do; 


/* convert 
~essege 
to 
hex 
formet 
*/ 


cAll 
cq~asc$hex(.cqmsiq,.msg); 


/* test 
for 
cete 
message 
receipt 
*/ 


if 
msc:.cmn<1 = 
2 


/* support 
receipt 
of 
oata 
message 
*/ 


ther. no; 


2S1 
7 
'2 '5.S 
7 
2 '5,r- 
7 
257 
7 
258 
7 
259 
7 
2~t) 
7 


2:'1 
7 


/* get 
ram 
from 
free 
space 
mana~er 
*/ 
req~msg.1pngth=]1; 
req$msg.type 
= 
5; 
req$msg.resronsp$exchange=.cq~ms$ex; 
reg$msg.msgSlength=msg.text(2); 
Cell 
rQsen0(.rgfsax,.reo$msg); 
msg$ptr=rowaitl.cc~ms~px,r); 
msg~ptr=reqSmsg.msg$length; 


/* move 
message 
into 
menory 
*/ 


cC'll 
move(msg.tf'xt(2) 
,.msCl.text(r.) 


,ms{J$pt r); 


/* 
if 
torget 
is 
(,!J'"lother 
node •. */ 


if 
msg.trgt 
> r 
then 
reJl 
rcsennl.cqniex(msg.trgt) 
,msg$ptr); 


2(j~ 
7 
9)) 


2t:;5 
..., 
I 
;;r.G 
7 
2"-7 
f 
L:':P 
f 


27(' 
P 
77J 
f 


then 
c211 
rc;scnC'(targeU'f'xch, 
IT'sgtptr); 


else 
do; 
r2rsize 
= nsg.text(7'; 
jf 
(rflmsize 
IT'OC") 
> r 


then 
nsg.text(2)=nsg.text(2) 


+ 
(11 
-(rensize 
mod 
11)); 


call 
rasenr(.rc;fsrx, 
msq~ptr); 


enc; 


2""" 
7 
, ~. 


27" 
7 


275 
7 


2""" 
r.: 
, ' 


/* 
increnrnt 
message 
counter 
*/ 


i f 
cqnr2 
r (n) 
• I a = 
J" 
tren 
ccmpar(n) 
.la 
= 
P; 
else 
('emf-rr(n).Jr=campr.:r(n) .1;>+J; 


enc1; 
/* respon~ 
to 
non-secuence 
2cknowlrcgp 
*/ 


if 
msg. cnr.<1 
c. 


inter 


2710 
(; 


2 C (1 
r 
" 
2P] 
..•, 


?P3 
7 


281, 
P 
22: 
p 


28'1 
P 
?f'7 
., 
I 


2P.P 
r; 


2P.S 
5 
2~r. 
!' 
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294 
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enc'; 
enc'l; 
end; 


/* test 
for? 
gooe' sl?ve 
L~ 
response 
*/ 


if 
cQnper(n) 
.n," = msg.seql2 
+ 
J 


thE"n cf'IJ 
error$tE"st; 
else 
('0; 
if 
nsg.seqle> 
<) 
cqmpC'r(n) 
.n .•• 


then 
cqcIT.cf(n) = cqcmff(n) 


or 
sync!"lreauE'st.; 
else 
(10; 
E"rror~count(n) 
= 
rj 
cqcmc'f(n) 
= cqcmcf(p) 
and 
not 
errorSfl?gj 
end; 
f"nel; 
enc'l; 
/* 
end 
of 
response 
ret.urn 
*/ 


/* 
support. 
of 
h,,(1 
c!"lec~sum */ 
else 
call 
errorrtest; 
enr.; 


/* E"nc'of 
messC'ge 
C'rrived 
options 
*/ 


/* enc'lof 
one 
node 
*/ 


/* end 
of 
t?sk 
*/ 


$title('SI~ve 
COMMunicptions 
P?ck2ge 
Version 
3./') 


CC~SLV~~Or.ULE: 
co; 


This 
is 
trp. sl?ve 
cOMmunic?tion 
M?in 
tpsk. 


It 
should 
be 
configurec 
into 
the 
system 
h?ving 
the 
following 
p?raMeters: 


T?s~ 
npme- 
COSL~V 
T?s~ 
entry 
point- 
CCSL~V 
T?sk 
priority- 
?s 
requirec 
Task'st?ck 
lp.ngth- 
1('0 


Th£ 
LINK 
and 
LOC~~E 
cO~M?nds 
of 
the 
us~r 


Tnl.t 
include 
the, foIJo\\:ing st?t:ements: 


:Fn:CQSL}\V.OBJ 
:Fn:CC'S35l.0BJ 
:Fn:CQCOTv'.LJB 
:Fn:CORSLV.LIP 


Several 
system 
par?Mcters 
must 
be 
0e~ined 


in 
the 
user 
code 
to 
cefine 
the 
mode' 


char~cteristics. 
These 
parr-meters 
are 
~efined 


as: 
coSsl?c- 
? byte 
value 
providing 
the 
nodAl 
address 
of'the 
commun- 
ic~tjon 
node. 
freSmeM- 
pn 
A0dress 
v?lue 
which 
provicps 


n 
pointer 
to 
p 
block 
OF 
P}\,..., 
to 


be 
assiane0 
vi~ 
the 
free 
sp~cP. 
manager-to 
the 
coMmunications. 
ramSlen- 
an 
address 
value 
which 
indic?tes 


the 
size 
of 
the 
ahove 
block. 


*/ 
declare 
cqsl?d 
byte 
extern?l; 


Snolist 
Sinclude(:fl:commsg.elt) 
~eclare 
msgSfOrM?t 
literally 
'structure 
( 


trgt 
bytp., 
cJT1nd 
byte, 
seaSla 
hyte, 
seqSna 
byte, 
text(25C') 
byte) 
'; 


declare 
queueSformat 
literelly 
'structure 
( 


endSptr 
byte, 
giveSptr 
byte, 
t?keSptr 
byte, 


51 
1 


52 
2 
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5-: 
1 
= 


:·5 
2 


= 


5(-; 
2 


57 
I 


Sf 
2 
5~ 
2 


nr 
'2. 


iiI 
1 


52 
'2. 


I'lJ 
'2. 


(;4 
1 


65 
'2. 


Gfi 
2 
(;7 
1 


fir 
2 


(, ~: 
2 


7(' 
/. 


71 
J. 


72 
2 
73 
2 


74 
1 


75 
2 
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? 
77 
] 


7P 
2 
7~ 
'2. 


pr 
2 
PI 
1 


P.2 
2 


~ecl2re 
p?rtformet 
liter?lly 
'structure 
( 
la 
bytE', 
nC' 
byte, 
run 
hyte, 
stop 
bytE', 
que$pt 
hyte) 
I; 
~inclune(:fr.:objmen.ext) 
RQCTfK: 
PROCEDURE 
(STATICtPTR) 
EXTEPN~L; 
~ECLARE 
STATICt-PTR 
ADDRESS; 


RQCXCH: 
PROCEDURE 
(EXCHANGESPTR) 
EXTERNAL; 
DECLARE 
EXCHANGESPTR 
ADDRESS; 


Et-'I:' 
RQCXCH; 
Sinclude(:fl:comcoM.ext) 
CQSNEXTSGIVE: 
Proce~ure 
(gSptr,giveSbyte) 
byte 
external; 
Declare 
qSptr 
annress; 
Dpclare 
giveSbyte 
hyte; 
enc 
cqSnext~~ive; 
C'"QSTI'KE$TEST: 
Procedure 
(qSptr) 
hyte 
extern;>l; 
Declare 
aSptr 
;>~dress; 
'"..•('q$tekeStest; 
CQSNEXTSTAKE: 
Procecure 
(q$ptr) 
byte 
externAl; 
Decl~re 
qt-ptr ancress; 
end 
cqSnextStakc; 
CQSQ$INI1': 
Procedure 
(qSpt.r,qSsi ze) 
extf!rna]; 
Declare 
qSptr 
aedress; 


Declare 
qSsize 
byte; 


end 
cqSqSinit; 
CQtASCSHEX: 
Procedure 
(qSpt r ,msgtpt r) 
externAl; 
Dee leere (q~ptr ,rnsgSpt r) aoC!ress; 
end 
coSascSrex; 
COSCHFCKSUM: 
Procedure 
(qt-ptr) hyte 
external; 
Declare 
q$ptr 
i'lndress; 
end 
cqSchec-I<sum; 
C('SHEX~"SC: 
Procenure 
(o~ptr,hexSbyte) 
extern;>]; 
DeclC're 
ctptr 
ac1c1ress; 
Declare 
hexSbyte 
byte; 


f'no cq$hex~c?sc; 
CQS".,SG$OUT: 
Procec1ure 
(msg~size,q$ptr,rerSptr,msg~rtr) 
external; 


Decl?re 
msqSsize 
hyte; 


inter 
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1 
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1 
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P-ecIe re 
(~Sptr, pC'r~ptr ,ms<:,Sptr) add ress; 


end 
cqSmsg~out; 


roSGEN$RDY: 
Procpcure 
(trget,msg~ptr,a~ptr,p?rSptr) 
external; 
Decl?re 
trget 
hyte; 


Decl? re 
(msg5ptr 
,q~ptr, 
Filrtpt r) aoc re.ss; 
enr' cqSgen$rdy; 


CO$GENSMSG: 
Proceoure 
(msg~pointer,trget,Msg~ptr,qSptr,p2rSptr,sev 
p~f 19) 
external; 


Decl?rc 
(trget,saveSfJg) 
byte; 


De c 12.re 
(M S 9 Spo i nte r ,m sCJt P tr ,aSp t r ,pC'rSp t r) 
?c1d res s ; 
enc 
cCl$genSmsgj 


Declere 
RQL(,FX 
intSexchange$oescriptor 
public; 
Peelere 
COfIEX 
pxchengeSoescriptor 
public; 


Dpclere 
cmrqex 
exch?ngeSrescriptor; 


ceclu" 
_ "rj rSsJ C've$cx 
exchange$desc 
ri ptor 
punl j c; 
Declare 
cqtime 
exch?nge~cescrirtor 
public; 


cq$st2.rtSmsgS35l: 
procedure 
external; 


end 
cqSstartSmsgS351; 


cqSinitS351: 
proceoure 
external; 


end 
cqSinit~351; 


finc1Sexch: 


procecure(nameSptr) 
address 
external; 


declere 
n2.Me$ptr 
cocress; 


end 
finc$exch; 


cq~startup: 
procecure 
external; 


enc' cgSstertup; 


~ecli1re 
caSinSsl 
qupuetforM?t 
public; 


ceclare 
cqSout~sl 
queueSformet 
public; 
c'eclilre msg 
msg~formct; 


decl?re 
ca~pilrs 
parSform?t 
public; 


declare 
freSmem 
edcress; 


cec]are 
cqcmcf(S) 
byte 
extern?l; 


oec10re 
freSmsg 
based 
freSmem 
structure 
msgShr r 
); 


The 
mcssege 
which 
is 
trensmittco 
between 
noces 


follows 
the 
description 
below: 


inter 


With 
the 
€xcpption 
of 
the 
stprt 
of 
text 
(~ 
Jine 
feed) 
pnr. 
the 
end 
of 
transmission 
(~ cprriage 
ret.urn), 
,>II 
ch?racters 
transmitt.ec1 
in 
t.he J:1eSsAge 
string 
•.... 
ill 
consist 
of 
print.i"ble 
ASCII 
chi'lr~cters. 


The 
target 
field 
consists 
of 
two 
fr?mes 
which 
represent 
the 
hex 
?deress 
of 
the 
~evice 
to 
which 
the 
~essage 
is 
ar.~resser.. The 
protocol 
?Jlows 
for 
up 
to 
25~ 
unique 
device 
addresses. 


The 
commnnc1 
fielc1 
inc1icat.es the 
type 
of 
mess~ge 
which 
is 
being 
sent 
in 
the 
network. 
Jt 
consists 
of 
a 
single 
fraJ:1e representing? 
hex 
nu~her 
in 
the 
range 
from 
r to rFH. 
The 
current 
message 
definitions 
pre: 


commanc1 


('I 
1 
2 
3 
4 
5 
6 


label 
INIT 
SYt-1CH 
Dl'.Tl>. 
REl>DY 
NOT 
REflDY 
NON 
rEO 
t.CK 
reservec' 


This 
is 
t~e 
J:1i'lin 
link 
level 
R~X/pr 
cOMJ:1unicptions 
task 
which 
supports 
sl~ve 
operi"tions 
of 
~ 
single 
bOrrd 
computer. 
Sever?l 
high 
level 
functions 
pre 
supported 
~y 
this 
te.sk. 


Messages 
containing 
C?t? 
mpy 
be 
sent 
or 
received 
by 
tris 
t?sk. 
To 
send? 
message 
to 
?nother 
processor 


on 
the 
communic~tions 
loop, 
a 
mess?ge 
of 
the 
format 
shown 
is 
placed 
into 
the 
communications 
exchange, 
CQSIEX. 
When 
the 
message 
has 
been 
transnitted, 
the 


RA~ 
area 
in 
which 
the 
message 
was 
loc?ter. 
will 
be 


returned 
to 
the 
free 
space 
J:1anager. 


Messages 
me.y also 
be 
received 
by 
the 
hoprr. when 
they 


are 
?dc1ressed 
to 
the 
communicptions 
pddress 
e.ssianec 


to 
tr·is board. 
,.Then p 
mess?ge 
r·i'S 
been 
receiver', -it. 


will 
be 
transferred 
to 
e. block 
of 
RA~ 
obte.ined 
from 
the 
free 
spC'ce mane.ger 
end 
then 
sent 
to 
2n 
excti'nge 
which 
is 
fesigni'ted 
in 
tre 
n2me 
fieJd 
of 
the 
messac;e. 


inter 


Ill; 
1 


115 
2 


11G 
2 
117 
? 
lIP 
2 


119 
'2 


120 
2 


121 
2 
In 
2 
123 
2 


12L1 
2 
125 
2 


1211 
2 
127 
2 
12e 
2 


129 
2 


13 r. 
3 


The 
formet 
for 
p 
~?tc 
Message 
is: 
msgShcr 
tPrgetex~h~ngenr.me 
mess?ge 


A speciel 
comm~nc, 
r~rT, 
cen 
be receivec 
by 
the 


communicetions 
driver 
t~sk w~ich 
will 
cause 
e 


software 
reset 
of the single 
boped 
computer. 


declpre 
tergettexch 
~€'cl?re neme 
Decli"re [!1sgtptr 
de·clerc rpmsize 


C'tc.c"ress; 
address; 
eedress; 
t?ddress; 


Declare 
RAM~msg 
bC'tsecMsg~ptr 
structure 
( 
msgShn r );' 


Declare 
req~msg 
structure 
msg~hc1r, 
MsgSlength 
eeeress 
); 
/* initiplize 
the tt?sk at power 
up */ 
call 
cq~qSinjt(.cqSin~sl, 
2SC); 
cell 
cqSqSinit(.cqSout~sl, 
250); 
cqSpers.run, 
cq$p~rs.stop, 
cqSpars.queSpt 
= C; 


/* huild 
required 
exchC'tnges*/ 
Coli 
rqcxch (.rqlf}ex); 
call 
rqcxch( .cqsiex); 
call 
rqcxch{.cmrqex); 
c?ll 
rqcxch (.cqtime); 
cpll 
cqinitS3S1; 


/* weit 
for e 
window 
from 
the wester 
*/ 
MsgSptr 
= rqweit 
(.ROL~EX, 
4r0); 


/* test 
for the 
receipt 
of 
e valic. messege 
*/ 


if coSchecksuM(.~qSinSsl) 
= C 
then (10; 


/* ~onvert 
the nessege 
into hex 
format 
*/ 


cpll 
cqSascShex(.cqSinSsl,.msg); 


1* see 
if mcssege 
is for this 
slpve 
hoerd 
*/ 


if msg.trgt 
= cqsl~d 
thf'n do; 


inter 


11;7 
10 
1(,3 
If, 


neme'= 
.msg.tp.xt 
+ 
9i 
cqcmdf(r) 
= cQcmdf(0) 
?nd 
7fh; 


/* r~ndle 
eecr. ness?gp. 
type 
by 
cese 
*/ 


do 
c?se 
msg.cmno; 


'/* 
Ci'se r., 
INTT 
commi1nd * / 


cell 
cqstc-rtup; 


/* r?se 
j, fYNCH 
cOM~?nd 
*/ 


~v; 


/* reset 
counters 
*/ 


cq~pi1rs.j~,cq~p?rs.n~ 
= 
r.i 


/.* init?ilfze 
G?t? 
queues 
*/ 


cC'll cq$qSinit 
(.cqnnSsl,2S0)i 


ei111 cqSq$init 
(.c~Sout$sl,250)i 


/* rpturn 
non 
seo 
i1ck message 
*/ 


msg.trgt 
= ri 
msg.cmnd 
= 
5; 
ci1rl ~qSmsg$out 
(0,.cqSoutSsl,.cq$ 


Ci1ll cqSstprt$msg3~li 


end; 


/* 
case 
2, 
C~TA,commi1nd 
*/ 


dOi 


/* test 
for 
correct 
N~ 
*/ 


if 
cqpi1rs.na 
= msg.seqSnp 


then 
dOi 


/* clei1r old 
meSSi1Qps 
*/ 


msg$ptr 
= 
rqi1cpt(.~old$sl?vPSe 


if msgSptr 
> 
(1 
tren 
c~ll 
returnSr?m(msgSptr)i 


/* 
increment 
L~ 
counter 
*/ 


if 
(cqSpi1rs.le:=cqSpers.li1+1) 


T~RGFTSEXCH 
= 
FINDSEXCHlnpme); 


if T~RGETSexch 
> r 


then 
(loi 


rpoSnsa.lenath 
= 
]li 


req$msg.typ; 
= 
5i 


inter 


In 
Ie 
179 
1 ] 


18P. 
11 


IF 1 
11 


H'2 
Ie 


I£:3 
<: 


1 p'/l 
P 
IPS 
9 
He; 
9 


IP7 
9 


189 
H 


ISO 
lr 


191 
If, 
192 
9 


rns9~ptr = RO~CPT 
(.cqsiex); 


if rnsgSptr = r 
then 
Cn!! 
co$genS rey (r, .msg, • 


else 
co; 
iff tnrgetSexch:= 
finc$exc 


else 
do; 
cell 
cqgenS~s~(msgptr, 


elsf" do; 
cqp?rs.n2 
= msg.Sf"~~nA; 


nsgSptr 
= 
rq~crt(.~o!~~sl?v~~e 


if msg~pt.r > r 
then 
~o; 
crl! 
cq$~en$nsg(nsg~ptr,r, 


enc1; 
enc; 


inter 


193 
194 


2 C] 
9 
202 
9 


2rL! 
9 
2C5 
Jr 


2r'7 
] G 


2r8 
1] 


2(;9 
11 


210 
J ] 
211 
]r 


/12 
9 


21: 
p 
21t. 
9 
215 
9 


2](; 
9 


21? 
Ie 


219 
}(1 


22C 
Ie 
221 
9 


/* 
sene 
messrgp. 
*/ 
crll 
cc~stprt~~sg~~~l; 
cn(l; 


/* 
c?se 
3, 
FDY 
commeno 
*/ 
00; 


/* 
verify 
n2 
is 
correct 
*/ 


if 
cq~p?rs.ne 
msg.seq$nr 


then 
ro; 


/* 
clPrr 
0]0 messaqes 
*/ 


~sg~ptr 
= 
ra~cptl.hol(lSslrve~e 


if 
~sgSpt.r 
> 
(' 


then 
cell 
returnSr2~lmsgSptr); 


~sgSptr 
= RO~CPT 
I.cqsiex); 


if 
~sgSptr 
= 
(1 
then 
cCl11 cq~gen~rdy 
IC,.msg,. 


else 
00; 
if 
ItargetSexch:=findSexch 


else 
~o; 
cell 
cqSgenSmsg(msgSpt 


eno; 
p.no; 


else 
do; 
capers.n? 
= 
msg.seq$nCl; 


msg~ptr 
= 
rQecptl.holo$s]pveSe 


if 
msgSptr 
> r 
then 
(lo; 
cell 
cq$genSmsglmsaSptr,0, 


end; 
end; 


inter 


222 
f' 


223 
P 


224 
7 


22:; 
7 


22P 
7 


23C 
.., 
I 


232 
7 


234 
7 


23(, 
7 


2JP 
7 


2f.C 
7 


242 
7 


2t.4 
7 


241) 
7 


2"1? 
7 
2 t:~? 
(, 


25(" 
5 
251 
4 


252 
3 
253 
t 
254 
r:: 
oJ 


255 
5 


25t; 
4 
257 
5 
25£ 
5 


c?]1 
caSst?rtSmsg~351i 


E' nr'l i 


1* c?se 
", 
~ONR~Y 
commend 
*1 
dOiE'nOi 


1* casE' 5, 
NONSEQACK 
command 
*1 
dOienci 


/* 
c~se 
n, 
reserved 
*1 
duiendi 


/* c?se 
7, 
reserved 
*/ 
dOiendi 


1* case 
8, 
reserved 
*1 
c'!oip.ndi 


/* 
case 
9, 
reserved 
*1 
dOiendi 


/* 
c?se 
A, 
reserved 
*/ 
c.oienci 


1* 
c?se 
B, 
reserved 
*/ 
dOienci 


1* C?SE' C, 
reserved 
*1 
dOiendi 


1* case 
D, 
reserved 
*1 
cloiendi 


1* 
c~se 
E, 
reserved 
*/ 
cloiendi 


/* case 
F, 
reserved 
*/ 
dOiendi 


endi 
/* co 
case 
*1 
endi 
/* 
good 
target 
*/ 
endi 
1* good 
checksum 
*1 
endi 
I*gooo 
communications 
with 
i~OS*1 


/* 
clear 
out 
messages 
if 
com 
failure 
exists 
*/ 


else 
dOi 
c'!o",hUe 
(msoSptr:=ra?cpt(.cosiex)) 
> 
Pi 


call 
return~ram(msg~ptr)i 


do 
while 
IlT'sgSptr:=rai"cpt(.hulclSsli"veSex)) 
> 
r.i 


call 
returnSram(msgSptr)i 
endi 


intel 


259 
·4 
2nC 
t 


2f;2 
2 
2(,3 
1 


cqcmcf(r) 
= cacmdf(C) 
or 
PCh; 


enc1; 


end; /* ~o 
fornver 
*/ 
enl' 
r:c$slC'v; 
enc 
comslvSnooule; 


inter 


Stitle('QUEUE 
INITI~Lr7.ATION 
PROCEDURE') 
O$INITt~ODULE: 
Do; 


c1ecl?re 
eorn literC'lly 
'r8I-l'; 


$include(:fl:cornmsg.elt) 


ceclare 
msg~format 
literelly 
'structure 
trgt 
hyte, 
cmnc1 
byte, 
scqSlc? 
hyte, 
seqSna 
hyte, 
text (25C) 
byte)'; 


(ler-L.a, queueSform<'lt 
lit.er<llly 'structure 
( 


en~$pti 
hyte, 
give~ptr 
byte, 
t?ke~ptr 
byte, 
(lc?taSbyte(254) 
byte) 
'; 


~ecl?re 
perSfor~at 
literally 
'structure 
( 
Ie 
byte, 
n2 
byte, 
run 
hyte, 
stop 
byte, 
queSpt 
hyte) 
,; 


Sincluoe(:f0:synch.ext) 
RQSEND: 
PROCEDURE 
(EXCHANGE$POINTF,R,~ESSAGF,~POINTF,R) 
EXTERNAL; 
DECLARE 
(EXCHANGE~Pr.INTER,MF,SSAGESPOINTER) 
ArDRESS; 


RQWAIT: 
PROCEDURE 
(EXCHJ.NGESPOINTER 
,DELAY) 
ADDRE:SS 
EXTERt-1A.L; 
P.ECLARE 
(EXCHANGE$POINTER,DELAY) 
ADDRFSS; 


RQ~CPT: 
PROCEDURE 
(EXCHJ.NGE~POI~TER) 
ADDRESS 
E~TERNJ.L; 
DECLARE 
EXCEANGE$POINTE:R 
ADP.RESf; 


R('IfNI:': 
PROCEDURE 
(IED~PTR) 
EXTERNAL; 


DECLARE 
IF.D~PTR ADDRESS; 


F.ND RQISND; 


$incluce(:f0:exch.elt) 
DECLARE 
EXCFJ.NGESDESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 
MSG$HEAD 
ADDRESS, 


~SG$TAIL 
ADDRESS, 


TJ.SKSHEAD 
lD8RESS, 


TASKSTAIL 
lDDRF.SS, 


inter 


NF.XT~F.xrp.~rDRF~E)'i 
;incluoe(:fr:msg.elt) 
DF.CL~RE ~SG$P.DP.LITERALLY 
, 
LINK 
rDCRESS, 
LENGTH 
'DDRE~~, 
TYPE 
BYTE" 


HO~EtF.XCH~NGE ~DDRE~S, 
RE8PCNSESEXCH~~GE 
~DDRESS'i 


rECL~pF. ~SGSDE~CnIPTrR 
LTTER~LLY 
'STPUCTUPE( 
t-1SG$HDR, 
REMJlI 
.•~lF:1 (]) 
BYTE) 
'; 


declare 
timex 
exchangc~~pscriptor 
extern?l; 
~cclpre 
rqfsrx 
exchpngeS~escrirtor 
extern~l; 
CQ$QSINIT: 
Proceoure 
(queueSptr, 
queue$size) 
reentrant 
pub 
lic; 
. 


/* 
This 
procedure 
i~itializes 
the 
queu~ 
pointers 
to 
indicate 
an 
empt.y queue. 


Declcre 
queueSptr 
podress; 
Declare 
aueue~size 
byte; 


end 
cCjSq"'init; 
end 
q$initSmocul€; 


F. 
1 


..., 
2 
I 


8 
2 


9 
1 


H 
? 


11 
2 


12 
1 


1: 
? 


14 
;:> 


15 
1 


] 
r:; 
2 


17 
2 


H 


~title('NEXT 
GIVE 
CUEUF. PROCEDURE, 
VERSION 
2.1') 
NEXT~GIVEt~ODULE: 
Do; 


~ecl~re 
eom 
literclly 
'r-DH'; 


Sinclure(:fl:commsg.elt) 
~ecl~re 
msgSfornat 
1iter~1ly 
'structure 
( 
trgt 
byte, 
cr.m~ 
byte, 
seqSI~ 
hyte, 
sC'qtno 
hyte, 


text (2<;0.)hyte 
)'; 


declare 
queueSformct 
liter~lly 
'structure 
( 
pnoSptr 
byte, 
giveSptr 
hyte, 
t?~eSptr 
byte, 
cl~t;lSbyte(25l!)byte)'; 


recl;lre p?rSformat 
literally 
'structure 
( 
Ie'! 
byte, 
n<1 
byte, 


luI: 
byte, 
stop 
byte, 
queSpt 
byte) 
,; 


Sinclude(:fr:synch.ext) 
RQr-END: 
PRCCEDURE 
(EXCH~NGE$prINTF.R,~ESS~GF$P0INTER) 
EXTFRN~L; 


rECL~RF. (EXCH~NGESPOJNTER,~ESS~GE$P0INTER) 
~DDRE~S; 


R0"':~.IT: 
PROCEDURE 
(EXCHANGESPOINTER,DELAY) 
ArORESS 
EXTERNAL; 
DECLARF. (EXCHAN~F.$POINTE~,DELAY) 
PDDRESS; 


RO~CPT: 


PROCEDURE 
(EXCH~NGE$POINTER) 
ADDRESS 
F.XTERNAL; 
DF.CLARE EXCHANGE$POINTER 
ADrREf,S; 


nQISND: 


PROCEDURE 
(IED$PTR) 
EXTERNAL; 


DF.CLARE IEDSPTR 
ADDRESS; 


END 
RQ ISf'!!:'; 


Sinclude(:fr:exch.elt) 
DECLARE 
F.XCHANGPSDESCRIPTOR 
LITERALLY 
'STRUCTURF. ( 
~SG$HF.~D ADDRESS, 
~SG~T~IL 
ADDRESS, 


TASKSHEAD 
JDDnESS, 


TISKSTAJL 
~DDnESS, 


24 
2 


25 
2 


26 
2 
27 
2 


2P 
2 


2£' 
2 
3C 
2 


32 
J 


JJ 
~ 


31! 
3 


35 
2 


NEXTtEXCH 
~DCRESS) 
'; 
tincluae(:fC:msg.clt) 
DECL~PE 
MSGSHPR 
LTTER~LLY 
, 
LH'K 
;'DDRFSS, 
LEr,ICTH ~DDPESS, 
TYPE 
BYTE, 
HO~F$EXCH~NGr. 
~DDRESS, 
RESPCNf.F.~EXCP~NGE 
~DDRFSS'; 


DECL~RE 
~SGSDESCRTPTOR 
LITERALLY 
'STRUCTURE( 
~SC$HI:'R, 
RE~1~INDF.R(1) 
BYTE) '; 


oecl2re 
timex 
exchange~cescriptor 
~xternel; 


~€T 
'..: r( 
rgfsrx 
E'xcpengeScescr 
iptor 
c:xterne I; 


rQ~NEXTSGIVE: 
Procpdure(OUEUEtPTR~GIVF.SBYTE) 
byte 
reentran 
t public; 
/* 
This 
procedure 
pIeces 
a 
byte 
into 
the 
cupue 
if 
room 


exists 
in 
tpe 
queue 
for 
that 
byte 
of 
aeta. 
If 
no 
room 
exists, 
a queue 
full 
indicetor 
will 
he 
returne~ 
by 


the 
proce0ure. 


Declere 
QUEUF.$FULL 
literally 
'0FFH'; 
Decl?re 
QUEUES OK 
literally 
'CArH'; 


Declere 
QUEUE$PTR 
~rdress; 
Decl~re 
(CTVE$BYTF,RSLT) 
hyte; 


/* Test 
for 
cueue 
full 
coraitipn 
eno 
if 
it 
is 
full, 


then 
insert 
end 
of 
messege 
*/ 


RSLT 
= queueSok; 
If 
(queue.GIVESFTR+l 
> 
oueup.ENDSPTR) 
then 
clo; 
rslt 
= aueueSfulJ; 
queue.c~teShyte(queue.giveSptr) 
pom; 


eno; 


> 
dueue.ENr~PTn) 
then 
oueue.GIVE~PTR 
('1'(1 ; 


~nc 
cq$nexttgive; 
enc 
next$aiveS~o~ule; 


inter 


() 
1 


7 
2 


P 
2 


9 
1 


Ir 
;> 


11 
:/ 


) 2 
1 


13 
2 


It. 
2 


15 
1 


H 
2 


17 
2 


lP 
1 


~title('GET 
CH1RACTER 
FRr~ 
QUEUE 
PRCCF.DURE') 
NEXT~TlKE~~0n~LE: 
Do; 


c('cl?re 
eorn litf'ri'llly'rDH'; 


~ inc I uc:' 
E' ( : f I : cOMrnsg •f']t) 
recJ?re 
msgSfor~?t 
literally 
'structure 
( 


t rgt 
byte, 


Cl'"'nr'l 
byt p , 
,..~,.tlc 
hyt.e, 
s£o~n? 
hyte, 
t ext (2 5 r) 
hy t e )'; 


cccl?re 
oueue~for~i'\t 
literi'llly 'structure 
( 
en<:'Sptr 
byte, 
giveSptr 
byte, 
takeSptr 
hyte, 
0?t?Sbyte 
(25<'1) 
byte)'; 


reclere 
perSfOrM?t 
literally 
'structure 
( 


la 
byte, 
nr! 
byte, 
run 
hyt.p., 
stop 
byte, 
que$pt. 
byte) 
,; 


Sinclufle(:fr,:syncp.ext) 
R('SEND: 


PROCEDURE 
(EXCH1NGE~POINTER,MESS~GF.SPOINTF.R) 
EXTERNAL; 
DECLlRE 
(EXCH~NGE$POINTER,~ESS~GEtPOINTER) 
ADDRESS; 


PQ\1'l' IT: 


PROCEDURE 
(EX~HANGFSPOINTER,DELl'Y) 
l'DDPE~S 
EXTFRN1L; 


DECLlRE 
(EXCH1NGESPOINTER,DELl'Y) 
l'DDRESS; 


POJlCPT: 


PROCEDURF 
(EXCHl'NGE~POrNTFR) 
l'DDPESS 
EXTERNAL; 
DECLARE 
EXCHANGE$POTNTER 
l'DDPFSS; 


RorSND: 


PROCEDURE 
(TED$PTR) 
EXTERNAL; 


DECLARE 
IEDSPTP 
l'DCRESSj 


RND 
RQISND; 


Sincluce(:f0:exch.elt) 
DECL1RE 
EXCH,lINGESDESCRIPTCR 


~SG$HE}lD 
lDDRESS, 


MSGSTAIL 
l'DDRESS, 
TAfKSHEAD 
lDDPFSS, 
Tl'~KSTAIL 
l'DDRESS, 


24 
2 
2~ 
2 


2~ 
2 


NEXTSf,XCR ~DDFFSS) '; 
$in~lurl€(:fr.:msg.elt) 
DECL~RE 
r~G~HDR 
LITF.RALLY 
, 
LINK 
JlDDRESS, 
LENGTH 
~DDRF.~f, 
TYPE 
BYTE, 
. 


HC~E~EXCfTJlNGE 
~DrRESS, 
RESPONSF.~r.XClll'NGF 
"DDRFS;"; 


DECLJlRE 
~SG~DEfCRIPTQR 
LITERJlLLY 
'fTPUCTURF( 
~fG$FDP., 
RF.!"'MNDFR(l) 
BYTE) 
'j 


~e~12re 
tinex 
exch~ng~~fescriptor 
externelj 


(~L_2rc 
rqfsrx 
pxchanget~pscriptor 
extern?l; 


c0t~rx~~1~KF: 
Procefure 
(qucueSptr) 
byte 
rcentrrnt 
puhli~; 
1* 
This 
typed 
proce~ure 
gets 
the 
next 
byte 
from 
the 


incic2ter 
queue 
~n~ 
returns 
it 
to-the 
cellin9 


progr2m. 
The 
oueue 
trk~ 
pointer 
i$ 
incremente~. 


Declare 
ou~ueSptr 
prrrcssj 
Dccl?re 
t?keShyte 
hytej 


If 
((queue.TJlKEtPTR:=oueue.TlKESPTR+l) 


. 
> 
queue.END~PTR) 
then 
queue.T~KE~PTR 
= 
0j 


enc 
cqSnpxtSt~kej 


en~ 
nextStrke~morulcj 


inter 


~titlc("fCII 
to HEX 
CONVERSION 
PROCEDURE') 


ASC~ ·~v~~OrULE: 
Do; 


~pc12re 
eom 
liter?lly 
'rrH'; 
~inclu0€(:f]:r.ommsg.elt) 
ree12re 
msg~forn?t 
liter?lly 
'structure 
( 


trgt 
hytP, 
emne" 
byte, 
s€'q~Ji' 
hyte, 
sec!~ne 
hyte, 
text(?5r) 
hyte 
}'; 


oec12re 
aueuetformet 
liter?Jly 
'structure 
( 


enc.~ptr 
byte, 
give~ptr 
byte, 
t?k~Sptr 
byte, 
c?t?Snyte(/.5J1) 
hyte 
) '; 


ceclC're 
p?rSformet 
]iter211y 
'structure 
( 
]2 
hyte, 
nM 
byte, 
run 
byte, 
stop 
byte, 
que$pt 
byte) 
, ; 


Sincluce(:fr.:syncr..ext} 
ROf;END: 
PROCEDURE 
(EXCHANGE$POINTER,MESSAGESPOINTER) 
EXTERNAL; 


rECLARE 
(EXCHANGE~POINTER,MESSAGESPOINTER) 
ADDRESS; 


FC1W,..IT: 
PROCEDURE 
IEXCHANCE$POINTER,DELAY) 
ADDRESS 
EXTFRNAL; 


DECLARE 
(EXr.HANGE~pnINTER,DELAY) 
ADDRESS; 


R('}\.CPT: 
PROCEDURE 
(EXCHANGE~POINTER) 
ADDRESS 
EXTERNAL; 


DECLARE 
EXCI1ANGEtPOINTER 
ADDRF:SS; 


ROISND: 


PROCEDURE 
(IEDSPTR) 
RXTERN1L; 


DECLARE 
IEDSPTR 
ADDRESS; 


END 
ROISND; 


Sinclude(:fC:pxrh.elt) 
DECLARE 
EXCHANGESDESCRJPTOR 
LTTERALLY 
'STRUCTURE 
( 
MSGSHE~D 
ADDRESS, 


~SG$TAIL 
ADDRESS, 
TASKSHEAD 
ADDRESS, 


TASKSTAIL 
JDDREfS, 


inter 


21 
1 


27 
1 


22 
1 


2<1 
2 


25 
2 


20 


27 
2 
28 
2 


2S' 
2 


3C 
2 


31 
2 
32 
2" 


3: 
2 


35 
2 


3E 
2 


38 
2 


3S 
2 


4r 
2 
41 
2 


42 
2 


NEXTtEXCH 
~DDRFSS) 
'; 
$incluc.e(:fr:~S0.elt) 
DECLARE 
~~GSHDR 
LITFRALLY 
t 
LINK 
.aDDRESS, 
LENGTH 
!'['CRFSE, 


TYPE 
PYTE, 
HO~F.SEXCHANGE 
ADDREf~, 
REfP0NSESEXCHANGE 
rDDRESS'; 


DECLARE 
MSC$DESCRIPTOR 
LJTER.l\LLY 'fTRUCTURF. ( 


~1SCSHDR , 
.o:..!' INDER 
(1 ) 
BYTE:)'; 


c.eclcrc 
ti~ex 
cxchange$descriptor 
rxtern?l; 
0cclare 
rqfsrx 
exch?ngeSdescriptor 
external; 


cqSnext$t?ke: 
procedure 
(aSpt r) 
byte 
exterf1i'd; 
declare 
qSptr 
eddress; 
pno 
cqSnextStake; 


This 
procedure 
tr?nsforms 
ASCII 
Gata 
in 
the 
input 


queue 
into 
2 hex 
string 
in 
the 
system 
mpss?ge 
storage 


a rea. 


Decle're 
(nchar,ch?r,n) 
l::yte; 


Ceclare 
(qSptr,msgSptr) 
address; 


/* throwaway 
the 
start 
of 
nessege 
*/ 
cJ~?r = 
cq$nextSteke(qSptr); 


/* convert 
message 
target 
e'dr-ress */ 
cher 
= cq$next.St2ke(qSptr); 
nchar 
= cq$nextSt.ake(qtptr); 


if 
char> 
.1Gh 
then 
char 
char 
- 
37h; 


else 
char 
= 
char 
- :Cr; 


if 
nch? r > 
40h 


then 
nch?r 
nchar 
- 
?7h; 
else 
nchar 
= 
nch?r 
- 
~rh; 


/* convert 
comMand 
byt.e */ 


ch?r 
= cqSnext.Stake(qSptr); 
if 
char> 
4Gh 
then 
char 
cher 
37h; 


else 
chAr 
= char 
- :r.h; 


<':4 
2 


4~ 
2 


4') 
2 


H: 
/. 


49 
2 


5(' 
2 


51 
2 


53 
2 


54 
2 


58 


") 


(,C 
< 


(,1 
3 


h3 
3 


(,1, 
3 


1';5 
3 
1';(, 
:- 


()7 
2 
oR 
1 


/* convert 
LP 
sequence 
*/ 
cher 
= 
cqSnextSt?ke(qtptr)i 


if 
cher 
> 
ll(1h 
tben 
ch?r 
chAr 
- 
~7hi 
else 
char 
= 
ch?r 
?rbi 


/* convert 
N~ 
sequence 
*/ 
char 
= 
cq~next$t?kp(q~p~r)i 


if 
c-h? r 
> 
Ll rh 
then 
ch"r 
ch?r 
- 
37h; 
else 
char 
= 
char 
- 
Jrhi 


n 
= 
Oi 
Do 
\·;hile (chcr:=cc;$nextSt?ke(QSptr)) 
<> 
r.OMi 


if 
ch?r 
> 
4r,H 
then 
ch?r 
char- 
e1ge 
ch?r 
= 
char 
37Hi 
3CHi 


if 
nchar 
> 
4rH 
then 
nchar 
nch?r 
- 
37B; 
else 
nch?r 
= 
nch?r 
- 
~0A; 


msg.text(p) 
n = 
n + 
1; 
enc:1; 


enc' CC;S?SCSheXi 
end 
?scShexSmodulei 


inter 


6 
1 


7 
2 
= 


8 
2 


C? 
1 


Ie 
.., 
/- 


11 
2 


12 
1 


12 
2 


111 
2 


15 
1 


16 
2 
= 


17 
2 


18 
1 


= 


Stitlef'HEX 
TO 
~ECII 
rONVERfION 
PROCEDURE" 
HEXS~SCS~ODULE: 
Do; 


'ecliHf' 
E'0l'1litE'rally 
'rnH'; 


Sinclu0e(:fl:commsg.eJt) 


oecl~re 
msgSformrt 
liter~lly 
'structure 
( 
trgt 
hyte, 
cmnd 
hyte, 
seq$12 
bytf', 
seq$n2 
hyte, 
text (25(;) 
byte)'; 


d€cl~re 
queue$for~rt 
liter?lly 
'structure 
( 


endSptr 
byte, 
giveSptr 
bytE', 
takeSptr 
byte, 
rlCltaSbyte(254) 
hyte 
) '; 


declere 
pnr$for~?t 
liter~lly 
'structure 
( 
In 
byte, 
n? 
byte, 
run 
byte, 
st.op 
bytE', 
queSpt 
byte) 
,; 


Sinclude(:f0:synch.ext) 
RQ8END: 
PROCEDURE 
(EXCH~NGESPCINTER,MESS~GE$PCI~TER) 
EXTERN~L; 


DEC.LARF 
(EXCH~NGE$POINTER,MESS~CE$POINTER) 
~DDRESS; 


R(l\"~ IT: 


PROCEVURE 
(FXCHANCESPCINTER,DELAY) 
ADDRESS 
EXTERN~L; 


DECL~RE 
(EXCHANGESPOINTER,DEL~Y) 
ADDREfS; 


RQJ\CPT: 


PROCEDURE 
(EXCHANGESPOI~TER) 
ADDRESS 
EXTERN~L; 
DECL~RE 
EXCH~NGE$POINTER 
ADDRE8S; 


RQISND: 
PRCCEDVRE 
fIrD$PTR) 
EXTERNAL; 


DECLARE 
IED$PTR 
ADDRESS; 


END 
RQISND; 


Sinclude(:fr:exch.elt) 
DfCLARE 
EXCHANGFSOESCRIPTOR 


MSGSHEAD 
ADDREfS, 


MSGSTAIL 
ADDRESS, 


TASKSHEAD 
ADDRESS, 


T~SKSTJ\IL 
ADDRESS, 


inter 


NF.XTSEXCH 
ArORESS) 
'; 
~incluc0(:fr:msg.elt) 
DECLIPE 
~SG~HDR 
LITF.R~LLY 
, 


LINK 
ADDFIESS, 
LFNGTH 
'·.DCRESS, 
TYPE· BYTE, 
HOME$EXCHANGF 
~DDnESS, 


RESPCNSE~EXCHANGE 
APDPESf'; 


DECL~FE 
MSG$DESCRIPTCFI 
LITF.RALLY 
'STRUCTURF( 
r~SG :~rR, 


RC: 
~:~_f 
(1) 
FYTE) 
'; 


<'lecJ?~ret·inex eXCr?ngeS(1escriptor 
f'xt€'rn;>]; 
reclare 
rgfsrx 
exch2nge$cescrirtor 
extern?]; 


cqSnextSgive: 
procerure(queSptr,dct?~byte) 
byte 
€'xternal; 
declare 
aueSptr 
?cdress; 
cecl?re 
rlat?Sbyte 
byte; 


pnd 
cq$nextSgive; 


This 
proce(1ure 
is 
used 
to 
convert? 
rex 
byte 
into 
two 


ASCII 
charpcters 
pnd 
store 
them 
into 
the 
next 
two 
loc- 
ations 
of 
the 
OSout 
fata 
crpa. 


Declare 
(highSbyte,hexSbyte,lowSbyte,st?tus) 
byte; 


Declere 
q$ptr 
a<'ldress; 


If 
(highShyte:=(shr(hpxSbyte,") 
2nd 
CFH)) 
> 
C' 


then 
highSbyte 
= 
highShyte 
+ 
37H; 
else 
highSbyt€' 
= 
highSbyte 
+ 
3CH; 


If 
(lowSbyte:=(hex$hyte 
rnd 
CFH)) 
> ~ 
then 
lowSbyte 
= 
lowSbyte 
+ 
37~; 
else 
lowSbyte 
= 
lowSbyte 
+ 30H; 


st"'tus 
status 
cqSnext$givP(.QSCUT, 
highSbyte); 
cqSnextSgive(.QSOUT, 
!owSbyte); 


return; 


enn 
cqShexSasc; 


end 
hexS?scSmodule; 


fi 
1 


7 
'2 


? 
2 


S 
1 


H 
'2 
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'2 
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1 


13 
2 
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2 
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1 
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$title('CHECKSUM 
C~LCUL~Tr0N 
PROCEDURE') 
CHECKSUM$~ODULE: 
ro; 
f 


(lecli're 
com 
litprclly 
'roil'; 
Sincluae(:f1:r.ommsg.plt) 
~ecl?re 
nsgSforn?t 
!iter~lly 
'structure 
trgt 
byte, 
cmnc 
bytp, 
seq$lC\ 
'"tf', 
sp.q$ni" 
byte, 
text (2 5r) 
by t e 
) ,; 


declpre 
queueSformat 
l1ter?11y 
'structure 
( 
endSptr 
hyte, 
giveSptr 
byte, 
tnkeSptr 
byte, 
cCltC'Sbyte (254) 
bytp 
)'; 


ceclare 
perSforn?t 
literCllly 
'structure 
( 
1'0 
byte, 
n? 
byte, 
run 
' byte, 
sto'p 
byte, 
q'ueSpt 
byte) 
,; 
Sinc1uoe(:fO:synch.ext) 
RQSENO: 
PROCEDURE 
(£XCHANGESPOINTER,~ESSAGESPOINTER) 
EXTERNAL; 


OECLA,RE (EXCH.aNGESPCHNTER, MEfS"GFS PO INTER) 
,.CDRFRS; 


RQ\>'J,IT: 
PR0.CEDURE (EXCF.~NGESPOINTER,DELAY) 
ADDRESS 
EXTFRNJL; 


DECLARE 
(FXCHANGE$POJNTER,DELAY) 
ADDRFf8; 


FQl'CPT: 
= 
PROCEDURE 
(EXCH~NGE$POJNT~R) 
~DDRES~ 
EXTERN~L; 


= 
DECL~RE 
EXCH~NGE~POJ~TER 
~DDRE~S; 


RQISl"D: 
PROCEDURE 
(IEDSPTR) 
EXTERN.aL; 
= 
~ECL~RE 
IEDSPTR 
ADDR~SS; 


F:l'1D RQI SND; 
Sincluc€(:fO:pxch.elt) 
DECLARE 
FXCH,.NGE$DESCRIPTCR 
LI~ER"LLY 
'STRUCTURE 
( 


= 
MSG~HE1L 
ADDRES~, 
MSGST.aIL ADDRESS, 
TAr.KSHEJOADDRESS, 
= 
TlfKSTATL 
lCOREfS, 


31 
2 


32 
2 


33 
;l 
3~ 
3 


3~ 
3 
':I"' 
3 
- 
I 


3£ 
3 


NEXTSEXCP 
ADDRESS) 
'; 
Sinc.iucp(:fr:rnsg.elt) 
DF.CL~RE 
~SGSHDR 
LITFR~LLY 
, 
LINK 
JlC'DRESS, 
LENGTH 
flDDRESS, 
TYPE 
PYTE, 
HC~E$F.XrH~NGF. 
lDDRESS, 
RESFO~SE~EXCHANGE 
~CDRESS'; 


DECLJlRE 
~SG$DFsrRIPTOR 
LITER~LLY 
'STRUCTURE( 
~SCSHDR, 
RE~'JI HIDER ( 1) 
BYTE) 
I , 


~pcl~re 
timex 
exchangeSdescriptor 
pxternal; 


~eclere 
rqfsrx 
excp?ngeSCcsc.riptor 
external; 
CQ$CHECKSUM: 
Procedure(qSptr) 
byte 
reentrant 
public; 


This 
procef.ure 
is 
used 
to cetermine 
the 
chec~sum 
of 


a 
mess~ge 
which 
has 
been 
received 
pnd 
stored 
into 


the 
Q$in 
huffer. 
A checksuM 
will 
be 
calcul~ted 
on 
pl1 


cherpcters 
beginning 
?t 
the 
start 
of 
text 
and 


continuing 
until 
the 
checksum 
hytes 
~re 
encountere~. 


This 
vplue 
viII 
he 
tested 
with 
the 
vplue 
trrnsmitted 


and 
if 
they 
egree, 
a value 
of 
z~ro 
will 
be 
returned 


to 
the 
cplling 
program. 
If 
not 
in 
agreempnt, 
p 


non-zero 
value 
will 
he 
returned. 


Declare 
(ptr,end$ptr,q$ptr) 
address; 
Declere 
(c.hecksm,strino$sum,char,n) 
byte; 


Declare 
1~stSchprs(3) 
hyte; 


PTR 
= 
O$IN.teYe$ptr; 
END$PTR 
= Q$I~.end$ptr; 


char 
= Q$IN.datp$r.yte(ptr); 
~o 
while 
char 
<> 
EO~; 
cppcksm 
= checksm 
+ c.har; 
if 
ptr 
= endSptr 
then 
ptr 
= 
v,; 
else 
ptr 
= 
ptr 
+ 
1; 
char 
= 
Q$IN.data$hytelptr); 
end; 


inter 


3S' 
;> 


"1 
7 
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/ 
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~ 


4t. 
:' 


ill; 
3 
47 
3 


ill" 
;> 
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~ 
<. 
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3 


52 
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2 
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:sr- 
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/* 
last 
three 
ch~r?cters 
in 
the 
mess~ge 
pre 
not 
include~ 
in 
the 
chFcksum, 
so 
they 
must 


be 
suhtr~ctec 
•••• */ 


/* first 
reme~ber 
the 
lest 
aueue 
location 
*/ 


if 
ptr 
= 
pnc~ptr 
tl-,encher 
r; 
else 
cher 
= 
ptr+l; 


,00 
n = r 
to 
2; 
checKsll1 = checksm 
- 
Il?stSch?rs(n):= 


OSJN.c1eteSbyte(ptr)) 
; 


. if 
pt r 
= r 
then 
ptr 
endSptr; 
else 
pt.r - .tr 
- 
J; 
end; 
checksm 
= 
checks~ 
+ 
Jrst~ch?rs(0); 


Do 
n = 
1 to 
;>; 
if 
l?st~ch?rs(n) 
> 
then 
l?stSchers(n) 
else 
lastSchers(n) 
enr; 
string$su~ 
= 
shUl?stSch2rs(?) 
,L1) 
+ 


l'0H 
last$ch?rs(n) 
= 
111st$cr?rs 
(n) 


- 37H; 
- :rR; 


if 
stringSsuM 
= 
checksM 
then 
return 
0.; 


else 
QSTN.t?keSptr 
= 
cheri 
return 
-]; 


enc 
cq$checksllM; 
enc 
checksumS~odule; 


inter 


r; 
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~title('GENFPJl'J'F' FEtDY 
f"FSSl>GF PROCEDlJflE') 
GE~~RDY~~OnULE: 
Do; 


~ecl~re 
eom 
liter2Jly 
'OQH'; 
Sinclure(:fl:coMMsg.clt) 
cecl2re 
nsg~form?t 
litercJJy 
'structure 
( 
trgt 
byte, 
cl'1nc 
byte, 
s",qSlr> 
byte, 
seq$n;> 
hyte, 
t ext 
('/ 5(J ) 
by t e 
)'; 


reelere 
queue$fornr>t 
liter?lly 
'structure 
( 
end$ptr 
byt€, 
giveSptr 
byte, 
t2ke$ptr 
byte, 
c'let2$byte(25il) byte) 
'; 


oecl?re 
perSforMnt 
liter211y 
'structure 
( 
12 
bytE', 
na 
bytE' . 


run 
byte, 
stop 
byte, 
que~pt 
byte) 
,; 


Sincluce(:fr:synch.ext) 
RQSEND: 
PROCEDURE 
(EXCHJlNGESPOINTER,MFSSJlGF$POINTER) 
FXTERNPL; 


DECL~flF 
(EXCHANGESPOINTER,f"ESSJlGESPOINTER) 
!'DDREES; 


FlQIA'A IT: 
PflOCEDURE 
(ExrHJlNCE$PCINTEfl,DFLJlY) 
ADDflESS 
FXTERNJlL; 
DECLARE 
(FXCHJlNGESPOINTER,DELAY) 
lDDflESS; 


RQJ\CPT: 
PflOCEDUflF 
(EXCHANGESPOINTER) 
ADDRESS 
EXTERNAL; 


DECLARE 
EXCHJlNGF.$POJ~TF.R 
ADDRESS; 


RQISND: 
PROCEDURE 
(IFD$PTR) 
EXTERNJlL; 
DECLJlRE 
IED$PTR 
lDDRFSS; 


END 
flQISND; 
Sincluc'le(:fO:excr..elt) 
DECLJlRE 
EXCHANGE$DESCRIPTOR 
LJTEflJlLLY 'STRUCTURE 
( 


MSGSHEAD 
PDDRESS, 
~SG$TAIL 
ADDRESS, 
TJlSKSP.EAD lDDRESS, 
TJlSK$TJlIL JlDDRFSS, 


inter 


NEXTtEXCH 
lDDRESS) 
'; 
$incluce(:fr:msg.clt) 
DECLARE 
~SGt"DR 
LITER~LLY 
, 
LINK 
.aDDRESS, 
LENGTH 
1'.DI:'RESS, 
TYPE 
BYTE, 
HO~E$EXCHANGE 
ADDRES~, 
RESPONSESEXCHANCE 
ADDRES~'; 


CECL1RE 
~SGSDESCP!PT0.R 
LITERALLY 
'STRUCTURE( 
1'1SCSPDP, 
RE~,a,INDER(1) BYTE)'; 


decl~re 
ti~px 
cxchangeSdescriptor 
cxternel; 
dec!ere 
rqfsrx 
exchrngeScescriptor 
pxtern~l; 


cq~f!lsg$out: 
procedure 
(msg$size,g$ptr,per$ptr,msgSptr) 
externel; 


oecJ2re 
msg$sizp 
byte; 
eecla 
re 
(qSpt r,p2 rSpt r,msgSptr) 
<lorrpss; 


ene 
ca$msgSout; 


COSGENSRDY: 
Procedure 
(trget,msgSptr,qSptr,prrSptr) 
reentr 


r'lntpublic; 


This 
procedure 
'generates 
a 
"ready" 
Mess2gp 
onto 
the 


communicFtion 
network. 
The 
tr'lrgetccdress 
is 
pessed 


~s 
the 
p~rem~ter 
in 
the 
c2ll. 


On 
entry 
to 
~he 
procedure: 
trget 
is 
e 
hyte 
~hich 
contains 
the 
2roress 


of 
the 
target 
node. 
msgSptr 
is 
an 
~odress 
which 
points 
to 
the 
RAM 
work 
~re?. 
qSptr 
is 
en 
cddress 
which 
points 
to 
the 
output 
queue. 
perSptr 
is 
2n 
2eeress 
which 
points 
to 


the 
communicction 
flegs. 


Decl2re 
trget 
byte; 


Decl?re 
rcySmsg 
structure 
TARCET 
byte, 
COMAND 
byte, 
SE(\SLl' 
byte, 


SEQSN1, 
byte 
cata 
( 
0,3,0,0); 


24 
2 


25 
2 
]t:; 
2 
37 
1 


return; 
enc 
cq~<.?€n~rc.y; 
enc 
gen$r~y~~o0ule; 


inter 


h 


7 
2 


8 
2 


9 
1 


lr 
2 


11 
2 


12 
1 


13 
;> 


III 
2 


15 
1 


1(; 
;;> 


17 
2 


lP 
1 


Stitle('DPT~ 
MESS~GE 
GENER~TOR 
PROCEDURE') 
GENSM~C$~ODULF: 
Co; 


r.ecl?re eom 
liter?lly 
'rDH'; 
$include(:fl:~oMmsg.elt) 
ceclAre 
msgSformet 
literrlly 
'structure 
( 
trgt 
byte, 
~Mno 
byte, 
seo$l(1 
hyte, 
seqSne 
byte, 
text (250) hyte 
)'; 


declare 
queueSformat 
literally 
'structure 
( 


encSptr 
hytr, 
giveSptr 
hyte, 
t(1keSptr 
byte, 
0At",Sbyte (254) byte)'; 


declrre 
perSformat 
liternlly 
'structure 
( 
1a 
byt e, 
ni" 
hyte, 
run 
byte, 
stop 
byte, 
,!ueSpt 
byte) 
,; 
Sinc!ude(:f0:synch.ext) 
RQSEND: 
PROCEDURE 
(EXCHANGESPOINTFR,~ESSAGESPOINTF.R) 
EXTERNAL; 


DECL~RE 
(EXCHANGE$POINTER,~ESSAGF$POINTFR) 
~DDRESS; 


RQI,rA.IT: 
PROCEDURF. (EXCHANGE$POINTER,DELAY) 
ADDRESS 
FXTERNAL; 


DECLARE 
(EXCHANGFSPOTNTFR,DFLAY) 
AD~RrfS; 


RQr,CPT: 
PROCEDURE 
(EXCHANGESPOJ~TER) 
ADDRFSS 
F.XTERNAL; 


DECL~RE 
EXCHANGF$POINTER 
PDDRFSS; 


RQlfNI:': 
PROCEDURE 
(IFD$PTR) 
EXTERNAL; 
DErLARF. IFD$PTR 
ADDRFSS; 


ENI' r.QISND; 


$incluoe(:fr:exch.e!t) 
DECLARE 
EXCH1NGE$DESCRIPTOR 
LTTFRALLY 
'STRUCTURE 
( 


~SG$HEAD 
ADDRESS, 


~SG$TIIL 
ADDRESS, 
TASK$HEAD 
ADDRESS, 
TASK$TAIL 
ADI'RESf, 


NEXT~EXCH 
fDDRF~S) 
'; 
tincluoe(:fr:msg.eJt) 
fFCL"RE 
~SCSHDR 
LJTERfLLY 
I 
LJNK 
l\DGRESS, 
LENGTB 
JlDDRESS, 
TYPE 
8YTE, 


HC~F.~EXCHJlNCE 
JlDDRF.S~, 


RESPCNSEtEXCIlJlNGF 
lIDDRESS'; 


CECLlIRF. />'SCSCr.SChJPTCR 
LJTER.~ LLY 
I STRUCTUPE 
( 
r~SGSf1DR , 
RE~"INDEn 
(1) 
P,YTE)'; 


~ecl2re 
tirnex 
exch?nget~escrirtor 
externel; 
c'cclr>re:rqfsri< 
exchengpSc1escriptor 
externAl; 


ccSmsgSout: 
procec.ure 
(msg$size,aSptr,perSptr,rnsgSptr) 
exter~r>l; 
declere 
nsg$size 
byte; 


cecl?re 
(a~ptr,p?r~ptr,msg~ptr) 
'?c('lress; 


end 
cqSmsgSout; 


CQSCENS~SG: 
Procedure 
(~sgSpointer, 
trget, 
msgSptr, 
qSptr, 
p8rtptr,s?ve$fl~) 
reentr?nt 
public; 


This 
procecure 
~ener?tes 
? 
cPt? 
messAge 
?nc 
pl?ces 


it 
onto 
the 
system 
comnunic?tions 
network. 


On 
entry 
to 
the 
procedure: 
msg$pointer 
is 
en 
?('ldress which 
points 
to 


the 
('let? to 
he 
trensmittec.. 
trget 
is 
cn 
hyte 
which 
conteins 
the 
eedress 
of 
the 
terget 
node. 
msgSptr 
is en 
ec1dress 
which 
points 
to 
the 
R~~ 
work 
cree. 
qSptr 
is 
en 
?oeress 
which 
point~ 
to 
t~e 
output 
queue. 
perSptr 
is 
2n 
er'r'rE'ss\;hich 
points 
to 
the 
conmunicetions 
flegs. 


Declpre 
(msg$pointer,rnsgtptr,qSptr,par$rtr,r?nSsi~e) 
? 


(10 ress; 
Declere 
(trget ,sr.weSf 19) 
byte; 


Dec1?re 
oetaSmsg 
structure 
target 
byte, 
com?no 
byte, 
seq$LlI 
byte, 
seq$NJI. 
byte, 
text 
byte 
) 
aeta 
(r,,2,r,C,r); 


inter 


3? 
2 


4(: 
3 


47 
3 
43 
: 


44 
2 
4~ 
2 


4f) 
1 


ceclere 
dct?~block 
b2S00 
msgtpointer 
structur~ 


nsaShd 
r ); 
/* 
mov~ 
mess?ge 
fornrt 
into 
messrge 
buffer 
*/ 


cC'IJ move 
(cl?teShlock.Jengt.h, 
JTisgSpointer, 
.msg.tp.xt(O 


) ; 


r?mSsizE' 
= 0etaShlock.length; 
call 
cqSnsgSout 
(ri"mSsize,qSptr,pClrSptr,msgSptr); 


if 
saveSflg 


then 
co; 
if 
ri"msizE' mod 
4 
> r 


then 
r?t?Shlock.length 
= rateSblock.length 
+ 
(4-(r 
en$size 
f.10C 
4)); 
cell 
RQSEND 
(. rqfsrx, 
msg$pointer); 


end; 


return; 
encl cqSgenSl'lsg; 
end 
genSnsg$moculE'; 


$title('iSEX 
35J 
ConMunic2tions 
Driver, 
Version 
I.?') 
~nointvector 
CQf35J: 
Do; 


This 
nocule 
~ontn.ins 
the 
physic2l 
interfec~ 
for 
support 
of 
tr.e Intel 
iSRX 
351 
communicetions 
expansion 


hoerd. 
The 
bo?r~ 
is 
inserte~ 
into 
soc~pt 
J~ 
~n~ 
h?s 
e 


b?s€ 
ed~rpss 
of 
FOH 
witr. th~ 
interrupt 
from 
the 


receiver 
strapped 
to 
trp 
interrupt 
level 
h. 
The 
tr2nsmitter 
interrupt 
is wiref 
to 
interrupt 
level 
5. 


~ulti-crop 
communicetior 
options 
ere 
supportec 
hy 
the 
physital 
softwere 
pec~ege. 


$incluce 
(:f0-:exch.elt) 
DFCLARE 
EXCH'NGESDESCRJPTOR 
LJTERALLY 
'STRUCTURE 
( 
~SGtHEAD 
ACCRFSS, 


~SGtT~JL 
ADDRFSS, 


T~SKSHE~D 
~DDRESS, 


TASKSTlIL 
~DDRESS, 


NEXTSEXIH 
'DDRESS) '; 


Sinclude 
(:f0:ieo.eJt) 


DECL'RE 
JNTSEXCHANGESDESCRIPTOR 
LITERALLY 
'STRUCTURE 
( 
MESSAGES HEAD 
ADDRESS, 


MESSAGESTAIL 
ADDRESS, 
T'SKSHEAD 
ADDRESS, 


TAEKSTAIL 
ADDRESS, 
EXCHANGFSLJNK 
ADDRESS, 
LINK 
ADDRESS, 
LF:NGTH I\DDRESS, 
TYPE 
PYTE)'; 


reclere 
R0LhF:X 
intSex~hengeSdescriptor 
externeJ; 


reclerr 
ROL7EX 
inttexcrenap~~escriptor 
externel; 


tincluce 
(:fl:commsg.€Jt) 


~eclare 
msgSformat 
literelly 
'structure 
( 


t.rgt 
hyte, 


cmnf 
byte, 
seaSlCl 
hyte, 
spq~na 
bytp, 


tpxt (25(1) 
byte)'; 


cecJrre 
queueSforMet 
JitereJJy 
'structure 
( 


encSptr 
hyte, 


giveSptr 
byte, 
tekeSptr 
hyte, 


(1?t2~byt€ 
(254) 
bytp. 
)'; 


inter 


12 


12 
2 


1" 
2 
] 
c; 
2 
= 


H 


17 
2 
1R 
2 
JS 
.l 
= 
2r 
;> 


21 
2 
22 
] 


23 
2 
2L' 
2 
25 
2 
2(, 
,.. 


27 
2 
2P 
2 
29 
] 
= 
:>r 
;> 
., , 
/. 
~.. 
37 
1 


33 
2 
31: 
/. 


35 
'2 


3r; 
] 


37 
/. 
38 
2 
29 
., 
/ 


LIe: 
1 


III 
2 
42 
2 
43 
2 


1" 
1 


L'5 
2 


J? 
bytp, 
ri 


ni' 
hyte, 
run 
byte, 
stop 
byte, 
qu€'~pt 
bytE") 
"~I 
Declere 
rCJNSL 
queu~~form?t 
cxt~rn?l;. 


Decl?rp 
C00UTSL'qu~ue~formct 
externel; 
Deelere 
rQP~RS 
r?r~formet 
externel; 


Sinclude 
(:fl:comcom.ext) 
CQSNEXTSGJVF.: 
. 


,Procedur~ 
(oSptr,giveSbyte) 
byte 
pxternal; 
Deelere 
qSptr 
D0rress; 
D0clere 
giveSbyte 
byte; 


~nd 
cqSnextSgive; 
C('ST"KESTEST: 
Procedure 
(qSptr) 
byte 
external; 


Declere 
o$ptr 
endress; 


end 
cq$tekeStest; 
COSNEXTST1,KE: 
Procecure 
(qSptr) 
byte 
externc'!; 
Declare 
gSptr 
address; 
end 
cq~next$takp; 
CQS()$INIT: 
Procedure 
IqSptr,qSsize) 
external; 


Declare 
qSptr 
erioress; 
I, 


Declare 
q$size 
byte; 


enc1 coSq$ init; 


CQSM:;C$HEX: 
. 
Procedu 
re 
(q$pt r ,msgSpt r) 
externe 1; 


Declare 
(qSptr,msgSptr) 
fldc'lress; 


enc 
co$?scShex; 


CCSCHECKf,UM: 
Procedure 
Iq~ptr) 
byte 
external; 


Declare 
qSptr 
adrress; 


enc 
co~chpcksum; 


CQSHEX$AfC: 
Proceeure 
(qSrtr,hexShyt~) 
extern?l; 


Declare 
q$ptr 
?rereSS; 
Declare 
hcxSbytehyte; 
.1 


ene 
ecSJ;(>xS?SC; 
'1, 


CCSf'!'SC$rUT: 


Procerure 
(msgSsi7P,qSrtr,p?r$ptr~msqSptr) 
externel; 


Declere 
msqSsizc 
hyte; 


DC'clere 
(oSptr,p'rSptr,msg:?ptr) 
edrress; 


cncl ccSmsgSout; 


C('SCENSrWY: 


Procccure 
Itrqet ,mso.~ptr ,oSptr ,p;:>,rSpt.r)externel; 
Declarp 
trqet 
hytp; 
reclC're 
(msgSptr,o$ptr,pClrSptr) 
cc'i'ress; 


rno 
cg$qen~rdy; 
CQSGENSJVlSG: 


Procefuce 
(~sgSpojntPr,trget,rnsgSrtr,a$ptr,per~ptr,s2V 


<,SfJg) 
extern;:>l; 
Declare 
(trget,s2\'E:Sflg) 
byte; 


inter 


L!r; 
? 
47 
2 


4f- 


t'! ~. 
'2 


5C 
'2 


51 
1 


57 
2 


53 
2 


511 


55 
2 


51) 
2 


57 


Sf' 
2 


59 
2 


(ie 


(,1 
2 


(,2 
1 


(,] 
2 


F.t. 
2 


(,5 
1 


ti!'i 
2 


07 
2 


6f' 


()9 
'2 
7r 
;:> 


71 
2 


7') 


73 
7- 


7/1 
2 


Dpclr.rc 
(msgtpojnt~r,msg~ptr,qSptr,p?r~ptr) 
?cc.rpss; 


~nc 
(;q~g€'ntnsg; 


Sincluce 
(:fr:synch.pxt) 


RQf-EN[': 
PRCCEDURE 
(EXC8~NGESP0INTER,~EffPGFtPOINTER) 
EXTERNAL; 


PECLARE 
(EKCH~NCFtPOINTFR,~EfSAGF$POINTER) 
JDDRFSS; 


PQI·"JI IT: 
PROCEDUPE 
(EXCH1\NGE$POJNTER,DEL1Y) 
Af'DRESS 
FXTERNA.L; 


DECLJlRE 
(EXCHANGFSPOINTER,DELAY) 
ADDRESS; 


R01CPT: 
PROCEDURE 
(EXCHANGFtPOIN1'FR) 
JlDDREfE 
FXTERNAL; 


DECLJlRF 
EXCBANGESPOINTER 
"DORERS; 


RQISf\'D: 
PROCEDURE 
(TED$PTR) 
EXTERNPL; 


DECLARE 
IFD$PTP 
ADDRESS; 


END 
RQISND; 


Sinc1uce 
(:fr:intrpt.~xt) 


RC'ENDr: 
PROCEDURE 
EXTERNAL; 


RQELVL: 
PROCEDURE 
(LEVEL) 
EXTERNAL; 
DECLARE 
LEVEL 
BYTE; 


RQDLVL: 
PROCEDURE 
(LEVEL) 
EXTERNAL; 
DECLARE 
LEVEL 
BYTE; 


RQSETV: 
PROCEDURE 
(PROC,LEVEL) 
EXTERNAL; 
DECLARE 
PROC 
ADDRESS; 
DECLARF 
LEVEL 
EYTF.; 


PQfETP: 


PROCEDURE 
(PROC,LF.VEL) 
EXTERNPL; 
DECLARE 
PROC 
l'DDRF.SS; 
DECLARE 
LEVEL 
PYTF.; 


p;> 
1 


P? 
2 


811 
2 
85 
2 
Ph 
:' 


87 
2 
88 
;> 
P9 
2 
~r. 
2 


91 
2 


0'" 
2 
_' 
L 


93 
2 
9~ 
2 
95 
2 
9~ 
2 
S? 
'"L 


DpclClu' 
EO'" 
literfllly 
'rDH'; 
/* defines 
eno 
of 
mpss2ge 
*/ 
Decl?re 
RTS 
liter?lly 
'f10JCrCrrb'; 
/* 
re?cy 
to 
send 
to 
US~RT 
*/ 
Decl?re 
RXE 
liter?lly 
'rrrrrJrrb'; 


/* 
ready 
to 
rec~ive 
to 
USART 
*/ 
Decl?re 
DTR 
literfllJy 
'rCrnr0JCb'; 


/* Ci"t? 
spt 
rc?dy 
to 
(Jf']\RT 
*/ 
Decl?re 
TXE~ 
liter?lly 
'0r.r0crrlh'; 


/* tr?nsw.it 
en?ble 
to 
U~JlRT 
*/ 
Ceclere 
h?~int 
byte; 
/* fl?g 
for 
interrupt 
5 
*/ 


Seject 
/********************************************************* 


Tris 
proceoure 
initi?lizes 
the 
r2rrW?re 
requirer 
to 


oper?te 
the 
iSPX 
351 
exp?nsion 
boerr. 


CQ$INITnSJ: 
Procedure 
public; 
Decl?re 
n 
byte; 


/* 
initialize 
the 
timer/counters 
*/ 
outputlCfbh) 
rb6h; 
/* select 
counter;> 
*/ 
output 
((1f2t~)= 
~2; 
/* 
lsb 
for 
24C1C 
b?uc1 */ 


output(Cf<lh) 
= 
0; 
/* 
l'!sbfor 
2L1r" 
b<lur */ 


/* initiclize 
the 
US~RT 
*/ 


output((1fJh) 
Pr.H; 
output(Cflh) 
r; 


output 
(rflb) 
trr; 
output 
((,flf') 
rcpr; 


op */ 
output(Cflh) 
2Gr; 


/* cle?r 
out 
g?rbaoe 
*/ 


/* 
... more 
q?rb?oe 
*/ 


/* 
reset 
tre-USJlRT 
*/ 


/* P bit, 
no 
p2rity, 
2 
st 


CJlLL rgsetv(.cqmivtS3~1, 
h); 


c?ll 
rasetv(.senctchC1rS351, 
5); 
cc,ll 
rgelvl 
( 5); 
c?ll 
rgelvl 
(11); 
return; 


end 
cqSiniH?5l; 


$eject 
/********************************************************* 


This 
procedure 
stores? 
cr?r?cter 
from 
the 
USJRT 
into 


the 
receiver 
r?ta 
input 
queue. 


Sf' 


9 S\ 
7 


1('r 
2 


HI 
2 


H2 
'2 


Hi 
2 


lC~ 
2 


HP 
7 


IJr 
3 


I 1 '2 
Ll 


II 
3 
f 


114 
il 


115 
3 


117 
f 
lIP 
11 
119 
5 
12" 
4 


171 
4 
177 
4 


122 
3 


174 
4 


125 
t 
12" 
5 
127 
f 


I?P 
4 


cot" IVTS3 51: 
Proceeure 
interrupt 
r, 
public; 
CecJpre 
(GIVEtST~TUS,CH~R) 
hyte; 


/* get 
chrrpcter 
from 
Uf~RT 
*/ 


ch?r 
= 
input(fFOh) 
?nr 
C7Fr; 
give$status 
= cqSnext~give(.cqinsl, 
ch?r); 


if 
ch?r 
= 
('om 
tr.en Ci'll rqisnd 
(.rq](jex); 
else 
ci111 rqenc.i; 


ene 
cqmivt$351; 
$eject 
/********************************************************* 
This 
procedure 
sen~s 
out 
the 
n~xt 
cr?r~cter 
to 
the 


selected 
US~RT 
device. 
It 
will 
c.is?ble 
the 
interrupt 


when 
?ll 
desired 
ch?racters 
r?ve 
been 
tr?nsmitted. 


********************************************************/ 
fEND$CHM/$ 
3 51 : 
Procedure 
interrupt 
5 public; 
Declare 
ch?r 
hyte; 


/* enable 
drivers 
?t 
h~ginning 
of 
MeSS?ge 
*/ 
If 
not 
copprs.run 
then 
do; 
cqpprs.run 
= 
1; 
cqpe-rs.stop 
= r; 
end; 


/* disrble 
drivers 
?t 
end 
of 
mess0ge 
*/ 
If 
cqp?rs.stop 
t.hen ~o; 
cqp?rs.run 
= 
C; 
Do 
while 
(inpuUrFlh) 
pne' 4) 
end; 
hpcint 
= 
C; 
output(0Flr) 


end; 


/* if 
~ess?ge 
is 
in 
rrogress, 
send 
next. ch?r?cter 
*/ 


else 
r'll); 
ch?r 
= 
cq~next$tare(.cqoutsl); 
do 
~;hi1e 
(input (flflh) and 
4) 
= r; 
enc; 
output 
(OF0h) 
= 
ch?r; 


/* test 
for 
end 
of 
mess?oe 
*/ 
if 
(ch<1r 
ant' 
~n) 
= 
com 


inter 


12 r. 
t; 


1?1 
4 
122 
2 


132 
? 


12<1 
? 


1:'5 
;> 


1?r, 
I 


127 
2 
1:;f 
2 
139 
2 
lIe: 
2 


HI 
1 


tr,en 
else 


('no; 
enc'; 


:: 1; 
c; 
C'qpprs.stop 
cqpnrs.stop 


/* re-enchle 
interr~rts 
*/ 


coIl 
rqenr'i; 


enf 
s€ne'Sc~8rS351; 


~eject 
/********************************************************* 


********************************************************/ 
COSST~RTSMSGS351: 
Procedure 
public; 


bC'c1int :: (Iffh; 
output(CFlh) 
25h; 


return; 


ene' cq~start$msg~?51; 
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An application 
system based on a custom hardware 
design will typically perform 
faster and require less 
hardware 
than if it were implemented 
with "off 
the 


shelf" 
circuit boards. 
However, these advantages 
are 


countered by the disadvantages of custom designs, with 
one of the largest drawbacks being the custom software 
required. This software is often unique to the applica- 
tion and specific to the hardware 
design, requiring a 


significant and increasing percentage of the develop- 
ment schedule and expense. The cost is multiplied by the 
need for software tools, standards, 
and maintenance 
developed specifically for each application. In addition, 
much of the application 
software cannot be used for 
new applications 
or hardware. 
All of these disadvan- 


tages can be significantly reduced by using a modular, 
standardized operating system. 


The operating system provides a higher level interface to 
the system hardware. The hardware characteristics com- 
mon to most applications, such as memory management 
and interrupt 
handling, 
are handled by the operating 


system 
rather 
than 
the 
application 
software. 
The 


operating system provides scheduling and synchroniza- 
tion for multiple functions, allowing application code to 
be written 
in independent 
pieces or modules. 
The 


operating 
system interface can be more standardized 
then the interface to the hardware 
components. 
This 


allows the application software to be more independent 
of changing hardware. The application code can be in- 
itially implemented and debugged on proven hardware. 
The software is then easily moved to the final hardware 
configuration 
for testing. 


8284 
CLOCK 
GENERATOR 


The operating system interfaces allow the use of stan- 
dard software tools, such as debuggers. Operating sys- 
tems also provide decreased debugging time and in- 
creased reliability 
through 
error 
checking and error 


handling. Perhaps most important, 
the expertise gained 


can be carried on to new designs based on the operating 
system. 


Operating 
systems have generally been described 
as 


large and complex, 
with rigid system requirements. 


Users have found it difficult to tailor a system to their 
needs or to use the operating system on more than one 
hardware configuration. 
System software has been ac- 


cepted in large pieces or as a whole, with few system 
configuration 
choices in either hardware 
or software. 


Those systems small enough to use on component 
de- 


signs have lacked extendibility to larger, more complex 
designs. 


The Intel iRMX 86 Operating 
System offers users of 


component hardware all benefits of operating systems 
while imposing 
few hardware 
restrictions. 
Minimum 


hardware 
requirements 
include 
1.8K RAM memory, 


enough RAM or EPROM memory to hold the Nucleus 
and the application code, and a handful of integrated 
circuits. The circuits are an Intel iAPX 86 or iAPX 88 
Central Processing Unit, an Intel 8284 Clock Generator, 
Intel 8282/83 Latches for bus address lines, an Intel 
8253 Programmable 
Interval Timer, and an Intel 8259A 


Programmable 
Interrupt 
Controller. 
Larger 
system 


busses will also require an Intel 8288 Bus Controller and 
Intel 8286/87 Transceivers 
for data lines. This basic 


hardware system is shown in Figure 1. 


inter 


Users with a wide range of applications 
will find the 


iRMX 86 Operating System allows them to implement a 
corresponding 
range of capabilities, 
from a minimum 


iRMX 86 Nucleus to a high level human interface. A 
complete iRMX 86 Operating System includes extensive 
I/O 
capabilities, 
debugger, 
application 
loader, 
boot- 


strap loader, and integrated user functions. This flexi- 
bility allows one operating system to be used for many 
projects, minimizing software learning curves for new 
applications. 


This note discusses a relatively small standalone spec- 
trum analysis system based on a subset of the iRMX 86 
Nucleus. The intent of the note is to demonstrate advan- 
tages of using operating systems in hardware compo- 
nent designs. An overview of operating system func- 
tions is given first as background information. 
Readers 


familiar with operating systems may wish to skip this 
section. The overview is followed by a summary of the 
iRMX 86 Operating System. The summary is brief, as 
only the iRMX 86 Nucleus is used in this application. A 
detailed discussion may be found in Application Note 
AP-86, "Using the iRMX 86 Operating System," 
and 


iRMX 86 System Manuals. 


The spectrum analysis system is described after the sum- 
mary. The system requirements, design and implemen- 
tation 
are detailed. The system software is discussed 


next, followed by configuration 
and hardware imple- 


mentation. 
A summary completes the application note 


text. Partial code listings of the system software are in- 
cluded in the appendices. 


OPERATING 
SYSTEMS 
FUNCTIONAL 


OVERVIEW 


Operating 
system 
software 
manage 
initialization, 


resources, scheduling, synchronization, 
and protection 


of tasks or functions within the system, as well as pro- 
viding 
facilities 
for 
maintenance, 
debugging, 
and 


growth. In general, operating systems support many of 
the following: 


Multiprogramming 
provides the capability for two or 


more programs 
to share the system hardware, 
after 


being 
developed 
and 
implemented 
independently. 
Within the environment 
of an operating 
system, the 


programs are called jobs. Jobs include system resources, 
such as memory, 
in addition 
to the actual program 


code. Multiprogramming 
allows jobs that are required 


only during development, such as debuggers, to run in 
the target 
system. When development 
is completed, 
these jobs are removed from the final system without af- 
fecting the integrity of the remaining jobs. 


Multitasking 


Multitasking allows functions within a job to be han- 
dled by separate 
tasks. 
This is particularly 
valuable 


when a job is responsible 
for multiple asynchronous 


events or activities. One task can be assigned to each 
event or activity. Tasks are the functional members of 
the system, executing within the bounds of a job en- 
vironment. Program code for a multitasking system is 
modular, with well-defined interfaces and communica- 
tion protocols. 
The modular boundaries 
serve several 


important purposes. The code for each module can be 
generated and tested independent of the other modules. 
In addition, 
the boundaries 
confine errors, 
speeding 


debugging and simplifying maintenance. 


The modular independence that results from multipro- 
gramming and multitasking gives users the ability to ef- 
ficiently create new applications by adding functions to 
old software. 
Applications 
can be tailored to specific 


needs by integrating 
new modules 
with previously- 


written general support code. If care is taken in system 
design, functions can be added in the field. Documenta- 
tion for the older software can be carried on to the new 
applications. This growth path will save completely re- 
writing expensive custom software for each new applica- 
tion. 


Scheduling 


Even though a system has multiple jobs and tasks, only 
one task is actually running on the central processor at 
any single point in time. Scheduling provides a means of 
predicting and controlling the selection of the running 
task from the tasks that are ready to run. Basic sched- 
uling methods 
include preemptive 
priority, 
non-pre- 


emptive priority, 
time-slice, and round-robin. 
Batch 
systems often use non-preemptive 
priority scheduling, 


in which the highest priority job gets control of the cen- 
tral 
processor 
and 
runs 
to completion. 
Preemptive 


scheduling is typically used in real-time or event-driven 
systems, where dedicated, 
quick response is the main 
concern. A higher-priority 
waiting task that becomes 


ready to run will preempt the lower-priority 
running 


task. Priority may be either set at task creation (static) 
or modified during running of the task (dynamic). 


Time-slice and 
round-robin 
scheduling 
are 
used in 


multiuser 
or multitask 
systems that share processing 


resources and have limits on maximum execution time. 
Time-slice scheduling gives each task or job a fixed slice 
of dedicated processor time. Round-robin 
gives each 


task or job a turn at using the processor. The time avail- 
able during the turn depends on system load and task 
priority. 


Communication 
and Synchronization 


Jobs and tasks in a multiprogramming 
and multitasking 


environment require a structured means of communica- 
tion. 
This communication 
may be necessary to syn- 


chronize processes or to pass data between processes. 
Two means of providing communication are mailboxes 
and semaphores. 
Mailboxes are an exchange place for 


system messages. The messages may include data or 
provide access to other system objects, including other 
mailboxes. Tasks can send objects to a mailbox or wait 
for objects from a mailbox. Generally, the task has the 
option of waiting for a specified period of time for the 
message. The wait time may range from zero for a task 
that requires immediate response to infinite time for a 
task that must have a message to continue processing. 
Multiple mailboxes are used to synchronize multiple 
tasks. 


A communication flow using mailboxes is shown in Fig- 
ure 2. In this example, the sending task sends a message 
to a mailbox and specifies a return mailbox. The send- 
ing task then waits at the return mailbox. The receiving 
task obtains the message from the sending mailbox and 
sends a message to the return mailbox. The first task 
obtains the second message from the return mailbox, 
synchronizing 
the 
two 
tasks 
and 
passing 
data. 


Figure 2. Intertask Communications with 
Mailboxes 


If process synchronization is the only requirement, sem- 
aphores may be used. Semaphores function like mail- 
boxes except that no data is passed through the sema- 
phore. Instead, semaphores contain "units," 
with the 


meaning of the units defined by the sending and receiv- 
ing tasks. A one unit semaphore may be used as a flag to 
synchronize the tasks. Multiple unit semaphores can be 
used for resource control. For example, if tasks require 
reusable data buffers, a semaphore may be defined as 
the allocator of the available data buffers. Each unit in 
the 
semaphore 
will represent 
one available 
buffer. 
When a task requires buffers to continue, the task will 
wait at the semaphore until enough units (representing 


buffers) are available. The waiting task will receive the 
units, 
use the 
buffers, 
and 
return 
the 
units 
(still 


representing buffers) to the semaphore. Other tasks that 
require buffers will also have to wait at the semaphore 
until enough buffers are available. 


The operating system is the central guardian of system 
resources, specifically read/write memory. The memory 
is made known to the Nucleus at initialization. 
The 


Nucleus then gives pieces or segments of the memory to 
tasks as they request it. This allows the tasks to have no 
initial knowledge of the actual location and size of sys- 
tem memory. Tasks can share memory if they desire, 
but the Nucleus allocates memory to each task individ- 
ually, preventing the tasks from using each others mem- 
ory. In addition, tasks return memory to the Nucleus 
when they are through with it, allowing memory to be 
reused. 


Other system resources, such as I/O devices, will also be 
scheduled by the operating system. The operating sys- 
tem is responsible both for the efficient use of these 
resources and for providing the tasks with a large mea- 
sure of independence from the actual I/O hardware re- 
quirements. The system may require many types of I/O 
devices, such as disk drives, tape drives, and printers. 
I/O is more efficiently accomplished 
if the operating 


system provides both asynchronous 
and synchronous 


I/O operations. 
Synchronous operations are those the 


task starts and waits for completion, 
doing no other 


work until the I/O is complete. Asynchronous 
opera- 


tions are started by the task, but the actual I/O can take 
place while the task is doing other work. The overlapped 
operation of asynchronous I/O provides more user con- 
trol of the I/O operation at the expense of a more com- 
plicated user interface. 


Interrupt Management 


Real-time software is tightly coupled to hardware func- 
tions by interrupts. Interrupts provide rapid notification 
that the hardware needs attention. 
The software must 


respond quickly without corrupting the system environ- 
ment. System integrity is preserved by preempting the 
lower priority operating task, saving the task environ- 
ment, processing the interrupt (including communicat- 
ing the results to other tasks if necessary), restoring the 
environment of the operating task, and continuing. All 
of this must occur in an orderly and efficient manner. 
The interrupt 
management 
of the operating system is 


responsible for directly interacting with the system hard- 
ware that detects interrupts. The interrupt tasks can be 
ignorant of the detailed interrupt hardware, 
providing 


only the system actions to service the event that caused 
the interrupt. 


Operating systems create and manage jobs and tasks at 
initialization as well as run time. Initialization generally 
must be done in a specific sequence which will depend 
on the environment existing at that time. An abortive in- 
itialization environment 
may require an orderly shut- 
down of the system. The operating 
system has the 


capability for managing these situations, including com- 
munications, 
access to system resource information, 


and displaying status of the initialization actions. 


Debugging 


The system debugger is a window into the internal struc- 
tures of the operating 
system. Debuggers allow data 


structures and memory to be examined, breakpoints to 
be set, and the user to be notified of abnormal condi- 
tions. The debugger may have symbolic debugging, in 
which system objects such as addresses, 
tasks, jobs, 


mailboxes, 
and 
memory 
locations 
can 
be assigned 


names. This gives greater flexibility and accuracy during 
debugging. The debugger may not be necessary in the 
final system, so the debugger is often a separate system 
job. This allows removal of the debugger with no effect 
on the remaining jobs. 


Debugging will be aided if the operating system verifies 
the parameters required by system actions and also re- 
turns status for the requested action. Parameter verifi- 
cation is particularly valuable for new program code in 
a developing system. Status results other than success 
are abnormal or exception conditions. Exception condi- 
tions may include insufficient memory for the request, 
invalid input data, inoperative I/O devices, an invalid 
request for an action, or a request for an invalid action. 
The operating 
system may have an exception handler 


for these conditions and may allow the debugger to be 
used as the exception handler. The development process 
will be more efficient if detection of exception condi- 
tions takes place for all levels of system actions, from 
initialization of jobs and tasks to requests for memory 
or status. 


With the continuing 
increase 
in system complexity, 


more operating systems are providing higher level func- 
tions. These functions may include advanced I/O file 
management, 
operator 
console, 
spooling operations, 


telecommunications 
support, multiuser support and ac- 


cess to system resources of increasing size and complex- 
ity. Only the largest operating systems provide all of 
these capabilities, 
but users of component 
hardware 


must be careful their system will integrate higher level 
functions that may be required in future applications. 


In order to provide general purpose support, operating 
systems must be extendible. New applications may re- 
quire data structures 
or system actions not available 


with the present operating system. The system must be 
able to integrate these new structures and actions, sup- 
porting them in the same manner as existing functions. 
Choosing an operating system requires a large commit- 
ment, both in initial expense and system architecture. 
Extendibility provides assurance the operating 
system 


chosen will not provide built-in obsolescence of that 
commitment. 


iRMX 86™ OPERATING 
SYSTEM 
ARCHITECTURE 


Layers 


The iRMX 86 Operating System architecture is shown in 
Figure 3. It includes the Nucleus, Basic I/O System, Ex- 
tended I/O System, Applications Loader, and Human 
Interface. These major portions of the operating system 
are designed as layers. Each layer may be added to 
previous layers as application needs grow. Lower layers 
may be used without upper layers. All layers may reside 
in programmable read only memory. Applications have 
access to all portions of the system, from the Nucleus to 
all outer layers. 


Figure 3. Architecture 
of the iRMX 86™ 


Operating 
System 


The Nucleus is the heart of the system. It includes sup- 
port for multiprogramming, 
multitasking, 
communica- 
tions, 
synchronization, 
scheduling, 
resource manage- 
ment, extendibility, interrupt handling, and error detec- 
tion. The Nucleus may be considered as an extended 
layer of the underlying hardware, giving the hardware 
system management functions and making the software 
independent of the detailed hardware. 
The system en- 
vironment, 
including resources, 
priorities, 
and place- 
ment of program code, is made known to the Nucleus at 
system initialization. 
All requests for memory, 
com- 
munication, and creation of basic data structures must 


go through 
the Nucleus. These requests are made by 


system calls, which are comparable to subroutine calls 
for system actions. 


All higher level functions of the iRMX 86 Operating 
System are built around a core of the Nucleus. Although 
outer layers may require a substantial 
number of the 


system functions included in the Nucleus, the Nucleus 
itself is configurable on a call-by-call basis. "Configu- 
rable" means the Nucleus may be altered so it contains 
code only for those functions required by the applica- 
tion. Certain features, such as parameter validation and 
exception handling, are also configurable. Features and 
system calls may be included for development and ex- 
cluded from the final system, giving a Nucleus tailored 
for each level of application development. 


The Basic I/O 
System is the first layer above the 


Nucleus. The Basic I/O System provides asynchronous 
I/O support and format independent 
manipulation 
of 


data. 
Multiple 
file types 
are 
supported, 
including 


Stream, Named, and Physical files. Stream files are in- 
ternal files for transferring 
large amounts of data be- 


tween jobs or tasks. Named files include data files of 
varying sizes and directories for those files. Named files 
are designed for random access disk storage. Physical 
files consider the entire device to be one file. Physical 
files are primarily used to transfer 
data to and from 


printers, tape drivers, and terminals. Device drivers for 
both 
floppy 
and hard 
disks are provided. 
Like the 


Nucleus, the Basic I/O System provides system calls to 
invoke I/O actions. These calls and the features of the 
Basic I/O System are fully configurable. 


The Application 
Loader provides the ability to load 


code and data from mass storage devices into system 
RAM memory. The Application Loader resides on the 
Basic I/O 
System, 
allowing application 
code to be 


loaded from any random access device supported by the 
Basic I/O System. Application code can be loaded and 
executed as needed rather than residing in dedicated 
system memory. 


The Extended I/O System supports synchronous I/O, 
automatic 
buffering, 
and logical names. Synchronous 


I/O provides a simplified user interface for I/O actions. 
Automatic buffering improves I/O efficiency by over- 
lapping I/O and application operations wherever possi- 
ble. Logical name support allows applications to access 
files with a user-selected name, aiding I/O device inde- 
pendence. 


The Human Interface uses all lower layers, forming a 
high level man-machine interface for user program in- 
vocation, 
command 
parsing, 
and 
file utilities. 
The 


primary purpose of the Human Interface is to support 
the addition of interactive commands. The Human In- 
terface is the basis for pass-through 
language support 


and multiple user systems. 


Configurability 


Configurability 
means the iRMX 86 Operating System 


can be changed to include only the system calls and 
features pertinent 
to the system under development. 


Smaller 
applications 
start 
with only 
the 
iRMX 
86 


Nucleus. A subset of Nucleus calls, described later in 
this application note, provide the basis for management 
of jobs, tasks, memory, interrupts, communication and 
synchronization, 
and support for the Debugger and Ter- 


minal Handler. 


All systems calls may also use parameter validation as a 
configuration option. Parameter validation verifies that 
system calls reference correct system objects before the 
requested action is performed. During debugging and in 
hostile environments, 
validation provides error detec- 


tion for each system call. This error detection does add 
some overhead to the calls. Debugged application jobs 
can perform 
more efficiently without the validation, 
while new code can use parameter 
validation to speed 


development. 


Once errors are detected, there are two means available 
to handle error recovery. The task can either use the 
status information to perform error recovery actions or 
the recovery actions may be performed by a specialized 
error handling program 
called an exception handler. 


Applications 
may use the Debugger as an exception 


handler, 
or use one implemented 
by the application. 


There are two classes of errors that may cause control to 
be given to an exception handler; avoidable errors, such 
as programmer errors, and unavoidable errors, such as 
insufficient memory. Exception handlers can be selected 
to receive control for either or both classes. 


Support Functions 


The iRMX 86 Operating System includes a Debugger, a 
Terminal 
Handler, 
a Bootstrap 
Loader, 
and a Patch 


Facility. The Debugger examines system objects, using 
execution 
and 
exchange 
(mailbox 
and 
semaphore) 


breakpoints, 
symbolic debugging, and exception han- 


dling. The Terminal 
Handler 
provides a line-editing, 


mailbox-driven 
CRT communications 
capability. 
The 


Bootstrap 
Loader 
is a fully configurable 
loader 
for 


bootstrap loading on reset or command, from any spe- 
cific random access device. The Patch Facility gives the 
capability of patching iRMX 86 Object Code in the 
field. 


Object Orientation 


The iRMX 86 Operating System is based on a set of sys- 
tem data structures called objects. These objects include 
jobs, 
tasks, 
mailboxes, 
semaphores, 
segments, 
and 


regions. Users may also define application-specific 
ob- 


jects. 
Object 
architecture 
includes the objects, 
their 


parameters, and the functions allowed with the objects. 


inter 


Object orientation 
is a formal, hardware-independent 


definition of hardware-dependent 
system structures that 


are currently used by most applications. 
For example, 


without object orientation, 
memory is reserved in ad- 


vance for system buffers. The application code knows 
buffer sizes and locations. If buffer requirements grow, 
requiring a new memory layout, much of the applica- 
tion code will change to accommodate 
the new buffer 


sizes and locations. 
Using object orientation, 
the ap- 


plication requests a segment (buffer) of a particular size 
when the buffer is needed. The Nucleus allocates the 
memory and returns a segment object to the applica- 
tion. If the application needs a larger buffer, it returns 
the old segment and requests a new one of a larger size. 
The application 
obtains more buffers by making re- 


quests for more segments. If the hardware changes, the 
iRMX 
86 Operating 
System is made 
aware of the 


changes. The application 
code uses the same system 


calls 
to 
request 
and 
return 
the 
segment 
objects 


regardless of the hardware configuration. 


Objects are provided for modular environments Uobs), 
application 
code 
functions 
(tasks), 
communication 


(mailboxes), 
synchronization 
(semaphores), 
memory 


(segments), and mutual exclusion (regions). Objects are 
fundamentally 
a set of standard interfaces between ap- 


plication code and the iRMX 86 Operating System. The 
standard interfaces have three primary benefits: 


1) First, objects provide structures, such as tasks or seg- 


ments, 
that are common 
to all applications. 
The 


structures form the basis for a standard set of system 
calls that make the interface between the application 
and the operating system more consistent and easier 
to learn. These calls allow applications to create more 
objects (segments for buffers, for example), delete 
them, change them, and inspect them. Development 
engineers can use their knowledge of the objects qn 
many applications, 
rath~r than just the one under 


development. The common objects allow a common 
system debugger to be used. The debugger will work 
for all applications, 
letting 
engineers concentrate 


their efforts 
on the application 
itself rather 
than 


designing and implementing custom debugging tools. 


2) Second, the standard 
characteristics 
of the object 


allow consistent error detection and handling. 
Re- 


quests to alter or use objects can be checked for 
validity before the Nucleus actually performs the re- 
quest. Errors can be classed as common to all objects 
or specific to certain objects, 
giving more precise 


error information 
for effective error handling and 


faster debugging. 


3) Third, the object interface will be preserved on future 


releases of the iRMX 86 Operating System. Current 
application 
code 
can 
be 
split 
into 
independent 
modules. Future applications can use the modules for 


common functions, preserving the investment in ap- 
plication software. 


Task Scheduling 


The Nucleus controls task scheduling by task priority 
and task state. Task priority is specified when the task is 
created. The priority can be altered dynamically. Tasks 
are classified into one of five classes: Running, Ready, 
Asleep, Suspended, 
or Asleep-Suspended. 
Tasks that 
have not been created are considered to be non-existent. 
The State Transition Diagram is shown in Figure 4. 


Only one task is in the Running state. This task has con- 
trol of the central processor. The Ready state is occu- 
pied by those tasks that are ready to run but have lower 
priority than the Running task. The Asleep state is occu- 
pied by tasks waiting for a message, semaphore units, 
availability of a requested resource, an interrupt, or for 
a requested amount of time to elapse. A task can specify 
the amount of time it will allow itself to spend in the 
Asleep state, but tasks in the Suspended state must be 
"resumed" 
by other tasks. The Suspended state is use- 
ful when situations require firm scheduling beyond the 
control provided by priority and system resource avail- 
ability. Examples of these situations are system emer- 
gencies, controlling tasks in the Ready state for applica- 
tion-dependent 
scheduling algorithms, 
and guarantee- 


ing a fixed initialization 
or shut-down 
sequence. 
If 


another task "suspends" 
a task already in the Asleep 


state, the sleeping task goes to the Asleep-Suspended 
state. This task will enter the Suspended state if the 
sleep-causing condition is satisfied. The task will go to 
the Asleep state from the Asleep-Suspended state if it is 
resumed before the sleep-causing condition is removed. 
If a task enters the Ready state and has higher priority 
than the present Running task, the ~eady task is given 
control of the CPU. Control is transferred 
to another 


task only when: 


1) The Running task makes a request that cannot im- 


mediately be filled. The Running task is moved to the 


Asleep state. The highest-priority 
Ready task be- 


comes the Running task. 


2) An interrupt occurs, causing a higher-priority task to 


become Ready. The current Running task goes to the 
Ready 
state, 
allowing the higher-priority 
task to 


become the Running task. 


3) The Running task causes a higher-priority 
task to 


become Ready by releasing the resource for which the 
higher-priority 
task is waiting. The current Running 


task goes to the Ready state. The higher-priority task 
becomes the Running task. 


4) The Running task causes a higher-priority 
task to 


become Ready by sending a message or semaphore 
units to the mailbox or semaphore where the higher- 
priority task is waiting. The. Running task is moved 
to the Ready state. The higher-priority task becomes 
the new Running task. 


5) The Running 
task removes a higher-priority 
task 


from the Suspended state by "resuming" 
it, placing 


the higher-priority 
task in the Ready state. The cur- 


rent Running task is moved to the Ready state and 
the higher-priority Ready task becomes the new Run- 
ning task. 


6) The Running task creates a higher-priority task. The 


new task goes to the Ready state. The current Run- 
ning task is moved to the Ready state and the higher- 
priority Ready task becomes the new Running task. 


7) The Running task places itself in the Suspended state. 
The highest-priority 
Ready task becomes the new 


Running task. 


8) The Running task places itself in the Asleep state. 


The highest-priority 
Ready task becomes the new 


Running Task. 


9) The Running 
task 
deletes itself, 
becoming 
Non- 


existent. The highest-priority Ready task will be the 
new Running task. 


System Hardware Requirements 


The iRMX 86 Operating System will run on any system 
that meets the following minimum hardware require- 
ments: 


I) An iAPX 86 or iAPX 88 Central Processing Unit. 


2) An Intel 8253 Programmable 
Interval Timer to pro- 


vide the system clock. 


3) An Intel 8259A Programmable 
Interrupt Controller. , 


4) Enough hardware to provide a system clock and bus 
interfaces. 
This may be supplied by the Intel 8284 


Clock Generator, 
Intel 8288 Bus Controller, 
Intel 


8282/8283 Latches, and Intel 8286/8287 Transceiv- 
ers. 


5) The following RAM: 


a. 1024 bytes from 0 to 1024 for software interrupt 


pointers (the interrupt vector). 


b. 800 bytes for Nucleus data. 


c. Enough RAM for the application data, code, and 
system objects. 


6) Enough EPROM or RAM to hold the required parts 


of the iRMX 86 Operating System and the applica- 
tion code. 


The Intel iSBC 86/12A Single Board Computer more 
than meets these minimum requirements. 
A block dia- 


gram of the board is shown in Figure 5. Note in addition 
to the timer and interrupt controller the board contains 
an 8251A USART, an 8255 parallel I/O interface, 
a 


MULTIBUSTM interface, 
four sockets for up to 16K 


bytes of EPROM, and 32K bytes of dual-ported RAM. 
Even though a user may be developing a custom board 
for his application, it is recommended that initial system 
development be accomplished using the iSBC 86/12A 
Single Board Computer. 
This will provide a known 


hardware environment to simplify debugging. In addi- 
tion, the development hardware system can be adapted 
to changing application needs by adding Intel MULTI- 
BUS compatible 
boards 
to the iSBC 86/12A 
Single 


Board Computer. After the software is fully debugged, 
the application can be moved to the final custom hard- 
ware design. 


A spectrum analyzer is the subject of this application. 
The analyzer displays the frequency spectrum 
of an 


analog signal on a general purpose CRT terminal. The 
user has control over input signal bandwidth, averaging, 
and 
continuous 
analysis. 
A fast 
Fourier 
transform 


(FFT) program is used to obtain frequency data from 
samples of analog data. Fourier transforms provide use- 
ful frequency analysis, but the large processing require- 
ments of Fourier transforms 
have restricted their use. 


Fast Fourier transforms take advantage of the repetitive 
nature of the Fourier calculations, allowing the Fourier 
transforms 
to be completed 
significantly 
faster. The 


FFT used in this application note is known as "time de- 
composition with input bit reversal. "I Sixteen-bit inte- 
ger samples of the input signal are placed in frames, 
with each frame holding 128 complex points. An aver- 
aged power spectrum is calculated to sum and square 
the FFT values, yielding 64 32-bit power spectrum 
values. These values are displayed on a standard CRT 
terminal. 


1. S. O. Stearns, Digital Signal Analysis, 
Hayden Book Co., Rochelle 


Park, 
NJ, 1975. 
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The FFT algorithm may be applied wherever frequency 
analysis of an analog signal is required. Medical appli- 
cations for FFTs include EEG analysis, blood flow 
analysis, and analysis of other low-frequency body sig- 
nals. Industrial uses are production line testing, wear 
analysis, frequency signature monitoring, analysis in 
noisy or hostile environments, and vibration analysis. 
Other applications could cover remote reduction of 
analog data, frequency correlation, and process control. 
For this application note, the actual use of the FFT is 
secondary to its existence liS a modular, CPU-intensive 
task in a general purpose system. 


The overall application system characteristics are the 
following: 


1) A user-selectable input signal bandwidth of 120 Hz, 


600 Hz, 1200Hz, 6000 Hz, or 12,000 Hz. 


2) The option of averaging frames of samples. The 


averaging is user selectable, with options of 1 (no 
averaging), 2, 4, 8, 16, or 32 frames averaged per 
CRT display. 


3 )The capability, also user selectable, of repeating the 


analysis cycle continuously. 


4) User capability to abort the analysis. 


5) Twelve-bit input sample resolution. 


6) A minimum of hardware requirements, including no 


more than 32K bytes of EPROM memory and 16K 
bytes of RAM memory. 


7) A standard character screen CRT for output. 


8) A multitasking structured design that will use a 


subset of the iRMX 86 Nucleus and exhibit modular 
application 
code, 
formal 
interfaces, 
and 
self- 
documentation. 


To begin the design, the application is broken up into 
functional modules, much the same as a hardware block 
diagram. A SUPERVISOR TASK initializes the system, 
accepts operator parameters, starts the analysis cycle, 
and stops the processing upon cycle completion or 
operator request. An INPUT TASK samples the data 
and places it in a buffer. An FFT TASK receives the 
buffer and processes the data. An OUTPUT TASK dis- 
plays the data received from the FFT TASK. This struc- 
ture is shown in Figure 6. 
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The general task functions are: 


SUPERVISOR TASK: The SUPERVISOR 
TASK ini- 


tializes the system by creating the other tasks. 
The 


SUPERVISOR TASK then obtains the analysis param- 
eters from the operator. Each parameter is verified as it 
is received. When all of the parameters are accepted, the 
operator is asked if they are satisfactory. If the operator 
agrees, the SUPERVISOR 
TASK sends frame buffers 
to the INPUT TASK to initialize the analysis. If not, the 
operator is asked to input all of the parameters again. 
During the FFT analysis, 
the SUPERVISOR 
TASK 


waits for an abort request from the operator and for the 
frame buffer from the OUTPUT TASK. If the abort re- 
quest is received, the SUPERVISOR TASK terminates 
the analysis in an orderly fashion and asks the operator 
for parameters for the next analysis cycle. If the frame 
buffer is received from the OUTPUT TASK and con- 
tinuous analysis has been selected, the SUPERVISOR 
TASK sends the frame buffer to the INPUT TASK to 
start the next cycle. If the frame buffer is received from, 
the OUTPUT 
TASK and continuous 
analysis has not 


been selected, the current analysis is complete and the 
SUPERVISOR TASK asks for new parameters. 


INPUT TASK: The INPUT TASK 'receives the frame 
buffer from the SUPERVISOR TASK. The input signal 
is sampled according to the analysis parameters. 
The 


actual sample rates are calculated as follows: 


1) Multiply the highest frequency of interest by two to 


obtain the Nyquist sampling rate. 
2) Invert this value to obtain time between samples. 
3) Scale the value by 60/64. The CRT display is limited 


to 64 columns. The scaling maps sample values to 
columns 1 to 60 rather than 1 to 64, giving a more 
readable x-axis label and display. This method yields. 
sample times of 3.9 milliseconds, 781 microseconds, 
390 microseconds, 
78 microseconds, 
and 39 micro- 


seconds for frequencies of 120 Hz, 600 Hz, 1200 Hz, 
6000 Hz, and 12,000 Hz. 


The INPUT TASK samples the data at the required 
interval and places the samples in the frame buffer. 
When the frame buffer is full, the INPUT TASK up- 


dates the frame buffer number and sends the frame buf- 
fer to the FFT TASK. The INPUT TASK sends a status 
message to' the CRT terminal and waits for the next 
frame buffer. 


FFT TASK: The FFT TASK receives the frame buffer 
from the INPUT TASK. A fast Fourier transform 
is 


performed 
on the data contained 
in the buffer, 
the 


power spectrum is calculated, and the data is averaged 
with previous data if necessary. If the frame buffer is 
the last one to be averaged prior to display of the fre- 
quency data, the frame buffer is filled with the averaged 
data and sent to the OUTPUT TASK. If the buffer is 
not the last one to be averaged, the FFT TASK returns 
the buffer to the INPUT TASK for another frame of 
data or to the SUPERVISOR TASK if the analysis cycle 
is nearly complete. The FFT TASK sends status infor- 
mation to the CRT display and waits for the next frame 
buffer from the INPUT TASK. 


OUTPUT TASK: The OUTPUT 
TASK receives the 


frame buffer from the FFT TASK. The data is format- 
ted and displayed. 
The OUTPUT 
TASK sends the 


frame buffer to the SUPERVISOR TASK and waits for 
the next frame buffer from the FFT TASK. 


Terminal Handler: The Terminal Handler serves as the 
basic I/O device for parameter 
requests, status data, 


and frequency displays. The Terminal Handler accepts 
display requests from all tasks and sends operator input 
to the SUPERVISOR TASK. 


The basic functions of the various tasks in the applica- 
tion have been defined, but system integration has not 
been discussed. Synchronization 
of the tasks, schedul- 


ing, resource management, mapping to hardware, inter- 
rupt handling, and system interfaces have been omitted. 
No debugging functions have been defined. It is clear 
the system implementation is just started. The iRMX 86 
Nucleus 
will provide 
all of the system integration 
"glue" 
the application 
requires, 
allowing application 


programmers 
to concentrate 
on the actual functional 
code. In order to use this "glue," 
the application must 


be divided into jobs and tasks. 


The iRMX 86 Operating 
System architecture 
defines 


jobs as separate environments within which tasks oper- 
ate. These separate 
environments 
allow each job to 
function with no knowledge of other system jobs. There 
are two jobs in this application, 
the Debugger job and 


the Application job. 


The jobs contain functional portions or working pro- 
grams called tasks. The Application 
job contains the 


INIT TASK, SUPERVISOR 
TASK, INPUT 
TASK, 


FFT 
TASK, 
OUTPUT 
TASK, 
and 
INTERRUPT 


TASK. The Debugger job contains the Debugger task 
and the Terminal Handler task. Tasks provide the ap- 


plication goals of modularity, resource constraint boun- 
daries, and functional independence. 
The structure of 


the development system is shown in Figure 7. 


Figure 7. Development System Job Structure 


The Debugger job is included only for development. 
When development is completed, the Debugger job is 
removed from the system. A Terminal Handler job con- 
taining only the Terminal Handler task is substituted in 
place of the Debugger job. The application code is not 
changed. This structure is shown in Figure 8. 


Figure 8. Final System Job Structure 


Interfaces and Synchronization 


Now that the system is made of jobs and tasks, the 
primary need is to synchronize the tasks and provide 
communication interfaces. This will be handled by mail- 
boxes. The messages sent via the mailboxes will be seg- 
ments, which are pieces of memory allocated by the 
Nucleus. The frame buffers sent from task to task are 
these segments. The buffer segments contain 
all the 


analysis parameters 
in addition 
to the data samples. 
Communication 
with the Terminal Handler task is also 


accomplished by mailboxes, but with a different buffer 
format. The Terminal Handler format has fields for the 
operation 
requested 
(read or write), the number 
of 


characters the task wishes to read or write, the number 


of characters the Terminal Handler did read or write, a 
status field for the operation, 
and the actual data. The 


buffer format is shown in Figure 9. Figure 12 contains 
the Terminal Handler segment format. 


SAMPLES 
PER FRAME 


SAMPLE 
INTERVAL 


FRAMES 
TO AVERAGE 


CONTINUOUS 
FLAG 


THIS 
FRAME 
NUMBER 


NUMBER 
SAMPLES 
MISSED 


SAMPLE 
POINTER 


RESET 
FLAG 


DATA 
SAMPLES 


DATA 
SAMPLES 


Figure 9. Frame Buffer Format 


Mailboxes are used to pass the buffer segment from task 
to task. 
Tasks can send segments to mailboxes, 
or 


receive segments from mailboxes. If there is no segment 
at a mailbox, a task can elect to wait for the segment, 
with the wait duration 
ranging from zero to forever. 


This provides the simplest system synchronization 
- 


each task, upon initialization, waits at its input mailbox 
for a frame buffer segment. When the task receives the 
segment, it processes the data, sends the segment on to 
the mailbox for the next task, and returns to its own 
mailbox to wait for the next frame buffer. The system is 
synchronized and controlled by the availability of frame 
buffers and task priority. It should be clear that multi- 
ple frame buffers segments provide overlapped process- 
ing, with the segments ultimately 
"piling 
up" 
at the 


slowest task in the chain. This loose coupling arrange- 
ment allows tasks to have radically different execution 
times. For example, the INPUT TASK has an input 
sampling time that ranges from 0.6 seconds to 6.3 milli- 
seconds, a range of 100 to I, and the system requires no 
special synchronization 
or scheduling to accommodate 


this range. 


The mailbox 
interfaces, 
shown in Figure 
10, serve 


several other important 
purposes. 
First, they provide 


the standardized interface that is a goal of this applica- 
tion. The set of mailboxes and the two buffer segments 
form all inter-task interfaces. Each task uses only a few 
mailboxes, making it easy to add or remove tasks by 
adding or removing mailboxes. The system could easily 
be expanded to include data reduction tasks, data cor- 
relation tasks, or to substitute different tasks for any of 
the present ones. Dummy tasks were used for real tasks 
during development to verify overall system execution 
before the actual tasks were available. 


inter 


Figure 10. Application Architecture with 
Mailboxes. 


The mailboxes also provide a very convenient window 
into the application system processing for both debugg- 
ing and aborting the current cycle. The Debugger can set 
breakpoints at mailboxes to allow users to examine the 
frame buffers as they progress from task to task. The 
Debugger can examine buffer data and control the pro- 
cessing cycle. Tasks wait at the mailboxes in a queue 
that is either priority or first-in-first-out 
(FIFO) based. 


The inter-task mailbox queues are priority based, which 
means the higher priority SUPERVISOR TASK can in- 
tercept segments at the mailboxes ahead of the lower 
priority waiting tasks, and abort the analysis by remov- 
ing all of the buffer segments. This method of aborting 
requires no knowledge of the internal processing of the 
tasks, making it universally applicable to all the tasks. 


A return mailbox may be specified when a segment is 
sent to a mailbox. The receiving task may send status in- 
formation, a different segment, or the original segment 
to the return mailbox. The Terminal Handler will return 


the buffer segment sent to it if a return mailbox is 
specified. This is used to synchronize the tasks with the 
Terminal Handler and to allow multiple tasks to use a 
single display task. Each sending task waits at a separate 
return mailbox for the Terminal Handler to return its 
segment. Each task retains control over its buffer seg- 
ment and is synchronized with the slower data display 
function. 


In addition to the mailboxes, task execution is governed 
by priority. In this system, the INPUT TASK has maxi- 
mum priority to guarantee it can sample the input signal 
at the precise intervals 
required 
for the FFT. 
The 


SUPERVISOR TASK, responsible for abort functions, 
has the next level of priority, with the FFT TASK next, 
and the OUTPUT TASK lowest. 


Display Functions 


All application tasks use the iRMX 86 Terminal Han- 
dier as an output 
device. The Terminal 
Handler 
is 


chosen because it provides a standard interface consis- 
tent with the application goals, it exists both in the De- 
bugger job and in an independent job, and it is easy to 
integrate into the application 
system. The application 


could also use the same interface with a user-written 
Terminal 
Handler. 
In this application, 
the Terminal 


Handler 
can have messages from four tasks on the 


screen at one time. To allow this to occur in an orderly 
fashion, lines on the screens are reserved for each of the 
tasks. The screen format is shown in Figure 11. Each 
message to the screen sends the cursor to the upper left 
corner (the home position), then down to the proper line 
to display the data. 
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Current 
settings 
are 
the 
following; 
frequency 
range 
0 to 
6000 
Hz, 
} 
SUPERVISOR 


16 
frames 
to 
average 
per 
output 
display, 
and 
continuous 
runs. 
TASK 


The 
INPUT TASK has 
processed 
16 
frames 
out 
of 
16 
frames 
to 
average. 
_ 
INPUT 
TASK 


The 
FFT TASK has 
processed 
16 
frames 
out 
of 
16 
frames 
to 
average. 
- 
FFT 
TASK 


Cataloging 


To aid the debugging process, all system objects, such as 
mailboxes, 
segments, and tasks, are cataloged in the 


directory of the SUPERVISOR TASK. The catalog en- 
tries are user-selected, 12-character names. The Debug- 
ger can display this directory, giving easy access to ob- 
jects to aid symbolic debugging. If other tasks know the 
proper directory and the 12-character name, the tasks 
can look up the objects in the directory and obtain ac- 
cess to them. This is the method used to find the Ter- 
minal Handler mailboxes. For objects that are cataloged 
only to aid debugging, the system calls that catalog the 
objects are removed from the code when debugging is 
complete. 


Application 
Code 


The code listings for the SUPERVISOR TASK and the 
INPUT TASK are included in appendices to this note. 
Code listings for other tasks are not included, but they 
are available from the Intel Insite software library. The 
following discussions reference line numbers in the list- 
ings included in this note. The references begin with a 
first letter for the appendix section (A or B), followed 
by the actual line number (A.220, for example). 


Code listings for the SUPERVISOR TASK are in Ap- 
pendix A. The actual SUPERVISOR TASK procedure 
begins at line A.550. After initializing internal buffers 
and mailboxes (A.55I, 
A.518-A.549), 
the Supervisor 


sends an initial screen, one line at a time, to the Termi- 
nal Handler (A.553, A.502-A.517). 
When the screen is 
complete, the SUPERVISOR TASK creates the INPUT 
TASK, 
FFT 
TASK, 
and 
OUTPUT 
TASK 
(A.554, 
AA86-A50l). 
The order of creation is not important 


for this application, as each task begins by waiting at its 
input mailbox for frame buffer segments. The SUPER- 
VISOR TASK requests input parameters from the oper- 
ator (A.556, A.305-AA85). 
The actual input parameter 


loop is found at AA78. 
The loop consists of asking 


questions (AA79, AA80) until all answers are satisfac- 
tory. The operator is asked to choose the highest fre- 
quency of interest, number of frames to average, and 
single runs or continuous 
runs (A.331-A.353). 
If the 


operator answers with an invalid input, the question is 
repeated (A.365 and AAI5). 
If the operator wishes to 


abort the questioning by entering a 99, the questions 
start over from the first question (AA09-AA13). 
When 


all three questions have been answered, the operator is 
asked to confirm his choice (AA82, 
AAI8-AA67). 
If 


the operator does not verify the answers, the question 
number is set to 0 (AA63) and the parameters are re- 
quested again. If he confirms the answers as correct, the 
SUPERVISOR TASK creates up to three frame buffer 
segments (A.557, A.279-A.304). 
The SUPERVISOR 


TASK places the binary equivalents 
of the operator 
answers in the frame segments (A.284, A.292, A.300, 
A.269-A.278), 
and sends the segments to the input 


mailbox for the INPUT TASK (A.287, A.294, A.302). 


The SUPERVISOR 
TASK's background 
duties are to 
check its input mailbox for a segment from the OUT- 
PUT TASK and to check a return mailbox for an abort 
request 
from the operator 
(A.558, A.225-A.268). 
If 


segments are received at the SUPERVISOR TASK mail- 
box, the SUPERVISOR TASK sends the segments on to 
the INPUT TASK if the operator has chosen continuous 
runs (A.258). Otherwise, the SUPERVISOR TASK de- 
letes 
the 
segments 
(A.242-A.250). 
When 
all 
the 
segments 
have 
been 
deleted, 
which 
halts 
the 
FFT 
analysis, the SUPERVISOR TASK asks for operator in- 
put again (A.556). 


If an operator 
abort request is received, the SUPER- 
VISOR TASK, having higher priority than the FFT or 
OUTPUT TASKS, waits at their mailboxes to intercept 
the 
frame 
segments 
(A.243, 
A.249, 
A.207-A.224). 


When a segment is received it is deleted (A.219). The 
SUPERVISOR 
TASK also checks the INPUT TASK 
mailbox under abort conditions (A.244). This mailbox 
is FIFO based to allow the SUPERVISOR TASK to in- 
tercept the buffer segment ahead of the higher-priority 
INPUT TASK (A.523). The SUPERVISOR 
TASK in- 
put mailbox is also checked for frame buffer segments 
that may have been sent there by the OUTPUT TASK 
after the abort was requested (A.246). When all of the 
frame buffer segments have been deleted, the SUPER- 
VISOR TASK asks for operator input (A.556). 


Listings of the INPUT TASK are in Appendix B. After 
initializing the buffer for Terminal Handler communi- 
cations and the mailboxes for communicating with the 
INTERRUPT TASK and the Terminal Handler (B.335, 
B.302-B.333), the INPUT TASK waits at its input mail- 
box for a frame buffer segment (B.338). 


When a frame segment is received, the INPUT TASK 
updates the frame number counter kept by the INPUT 
TASK (B.340, B.289-B.301), and samples the analog in- 
put (B.341, B.231-B.288). 
The INPUT TASK selects 


one of two input driver routines, either a software poll- 
ing loop for faster sampling rates (B.277-B.281), or an 
INTERRUPT 
TASK 
for 
slower 
sampling 
rates 


(B.251-B.276). 
If the sampling is driven by interrupts 


and a Nucleus system call is executing at the time of the 
interrupt, the time required to respond to that interrupt 
can vary from 100 to 350 microseconds, depending on 
the Nucleus call in progress. For the sample rates of 391, 
78, and 39 microseconds, corresponding to bandwidths 
of 1200, 6000, and 12,000 Hz, the system interrupt 
latency cannot guarantee the precise sampling interval 


inter 


required. A a simple software polling loop with a delay 
between samples is used for these rates (assembler code 
for this loop is included after the INPUT TASK listings 
in Appendix B). This loop operates at priority 0, the 
highest priority, to guarantee the loop is not interrupted 
(B.278, B.280) while the sampling is in progress. 


For the longer intervals of 3.9 milliseconds and 781 
microseconds, corresponding to bandwidths of 120 and 
600 Hz, an Interrupt 
Handler and and INTERRUPT 


TASK are used (B.251-B.276). 
Under the iRMX 86 


Operating System architecture, an Interrupt Handler is 
defined as a short procedure with a primary goal of fast 
interrupt response and limited Nucleus calls. All hard- 
ware interrupt 
levels are masked when an Interrupt 


Handler is responding to an interrupt. 
If the interrupt 


servicing requires higher-level system functions, the In- 
terrupt Handler notifies a waiting INTERRUPT TASK. 
Higher-level interrupts 
are enabled when an INTER- 


RUPT TASK is executing. INTERRUPT 
TASKS can 


make all system calls. 


The INTERRUPT 
TASK (B.196-B.203) binds the In- 


terrupt Handler to the hardware interrupt level (B.197) 
and waits for a signal from the Interrupt 
Handler 


(B.199). The Interrupt 
Handler (B.I64-B.195) 
verifies 


the interval accuracy (B.166-B.173), 
samples the data 


(which automatically 
starts the next sample) (B.175- 


B.I76), 
places the data in the frame buffer (B.18I- 


B.184), and notifies the INTERRUPT 
TASK when the 


frame buffer is full (B.193). If the buffer is not full, the 
Interrupt Handler resets the interrupt hardware (B.194). 
The INTERRUPT 
TASK notifies the INPUT 
TASK 


(B.200) and waits for a return message (B.20I). The IN- 
PUT TASK disables interrupt 
level 3 (B.274) and re- 


turns the token to the INTERRUPT TASK (B.275). The 
INTERRUPT 
TASK enables 
the Interrupt 
Handler 


(B. 199), but no interrupts will be received from the free- 
running 8253 Timer because hardware interrupt level 3 
has been disabled. Sampling for the next buffer is in- 
itiated by simply enabling level 3 (B.272). The INPUT 
TASK sends a status message to the Terminal Handler 
(B.342, B.219-B.230) and sends the filled frame buffer 
to the FFT TASK (B.343). The INPUT 
TASK then 


returns to the INPUT TASK input mailbox to wait for 
the next frame segment (B.338). 


Listings for the FFT TASK are not included with this 
application 
note. The FFT TASK is similar in overall 


format to the INPUT TASK. The FFT TASK waits at 
its input mailbox for a frame buffer segment from the 
INPUT TASK. When one is received, the FFT TASK 
computes the fast Fourier transform 
of the data. The 


auto power spectrum is computed and averaged with 
previous data. The FFT TASK sends its status message 
to the Terminal Handler for display. If the frame buffer 


is the final one to be averaged, the FFT TASK sends the 
frame buffer to the OUTPUT TASK. If the frame buf- 
fer is not the final one in this averaging series, the FFT 
TASK checks to see if the sampling process is continu- 
ous. If so, the frame buffer is returned to the INPUT 
TASK. If the sampling process is not continuous 
and 


the buffer is within two frames of the final frame buf- 
fer, the buffer is returned to the SUPERVISOR TASK 
to prevent unnecessary buffers from going to the IN- 
PUT TASK. The FFT TASK then returns to its input 
mailbox to wait for the next frame buffer. 


OUTPUT 
TASK 


Listings for the OUTPUT TASK are not included in this 
application note. The OUTPUT TASK, like the other 
tasks, waits at its input mailbox for a buffer. When a 
frame buffer is received from the FFT TASK, the OUT- 
PUT TASK stores the data in an internal buffer and 
sends the frame buffer to the SUPERVISOR TASK. 


The OUTPUT TASK converts each 32-bit frame buffer 
value to one of 16 levels by taking the base 2 logarithm 
of the significant 16 bits of sample value. The display 
screen is sent to the Terminal Handler one line at a time. 
Each line of the display is composed of 7 characters of 
label and y-axis data and 64 characters of display data 
(reference Figure 11). Each line of the display represents 
a power oftwo (from 16down to I). The character to be 
displayed at each location is found by comparing the ap- 
propriate sample value against the current line value. If 
the sample value is greater than the line number, 
a 


pound sign is displayed at that location. Otherwise, a 
space is displayed. The x-axis and labels are sent after 
the data lines to complete the display. The OUTPUT 
TASK then waits at its input mailbox for another frame 
buffer. 


The Terminal 
Handler 
interfaces 
to the application 


tasks via the two mailboxes and buffer segment format 
shown in Figure 12. If a task wishes to display data, a 
segment containing the data is sent to the RQ$TH$- 
NORM$OUT 
mailbox, 
specifying a return 
mailbox. 


The Terminal Handler displays the data, updates the. 
status 
fields, and 
sends the segment 
to the return 


mailbox. 


Input 
proceeds 
in much the same fashion. 
A task 


requesting 
data 
sends 
a 
segment 
to 
the 


RQ$TH$NORM$IN 
mailbox, again specifying a return 


mailbox. When the operator 
terminates the input line 
with a carriage return, the Terminal Handler puts the 
data in the segment, updates the status fields, and sends 
the segment to the return 
mailbox. 
This serves two 


primary purposes: 
specifying return mailboxes allows 


multiple tasks to share the display screen while retaining 


inter 


FUNCTION 
(READ 
OR WRITE) 


COUNT 
(N CHARS. 
TO READIWRITEj 


EXCEPTION 
CODE 
(STATUS) 


ACTUAL 
(N CHARS. 
READIWRITIEN) 


DATA 
SAMPLES 


synchronization and control over their data buffers; and 
a user-written 
Terminal Handler using the same pro- 


tocol and mailbox names could easily be integrated into 
the application. For this application, the INPUT TASK, 
FFT 
TASK, 
OUTPUT 
TASK, 
and 
SUPERVISOR 


TASK all share the screen for output, 
but only the 


SUPERVISOR TASK uses the Terminal Handler to ob- 
tain operator input. 


The iRMX 86 Nucleus provides a comprehensive set of 
61 system calls. A complete description of these calls 
may be found 
in the iRMX 
86 Nucleus 
Reference 


Manual. For most applications, only a subset of the 61 
calls will be required. The iRMX 86 Nucleus is configur- 
able, which means the final system Nucleus will contain 
code only for the system calls required for the applica- 
tion. 
In this case, the following 
system calls were 


required: 


RQ$CREA TE$MAILBOX, 
RQ$SEND$MESSAGE, 
and RQ$RECEIVE$MESSAGE 
provide mailbox man- 


agement. 


RQ$CREA TE$SEGMENT 
and 
RQ$DELETE$SEG- 


MENT are used to create and delete segments for the 
frame buffers, internal buffers, and Terminal Handler. 


RQ$SET$INTERRUPT, 
RQ$EXIT$INTERRUPT, 


RQ$SIGNAL$INTERRUPT, 
RQ$W AIT$INTER- 


RUPT, 
RQ$ENABLE, 
and RQ$DISABLE 
allow the 


INPUT TASK to handle hardware interrupts knowing 
only the hardware interrupt level (3). 


RQ$CREA TE$JOB, 
RQ$CREA TE$TASK, 
and 


RQ$SET$PRIORITY 
are used to create the jobs and 


tasks, and set the priority of the input polling loop. 


RQ$GET$T ASK$TOKENS, 
RQ$LOOKUP$OBJECT, 
RQ$CATALOG$OBJECT, 
RQ$DISABLE$DELE- 


TION, 
RQ$ENABLE$DELETION, 
RQ$GET$TYPE, 


RQ$GET$PRIORITY, 
RQ$GET$SIZE, 
and RQ$SIG- 
NAL$EXCEPTION 
are system calls required 
by the 


Debugger and the Terminal 
Handler. 
None of these 


calls are necessary in this application if a user-written 
Terminal Handler is used and debugging is completed. 


System Configuration 
is the integration 
step in the 
development process. It consists of selecting the por- 
tions of the iRMX 86 Operating System required in the 
application, mapping this code and the application code 
to system memory, and creating a Root Job that will in- 
itialize the system. The overall configuration 
process is 


shown in Figure 13. Configuration 
requires knowledge 


of available memory, operating system and application 
code entry points, priorities, 
exception handlers, 
and 


other system parameters. System Configuration consists 
of the following steps: 


1) Selecting the portions 
of the iRMX 86 Operating 


System required 
by the application, 
including the 
layers and the specific system calls in each layer. 


2) Linking and locating those portions. 


3) Assembling or compiling, linking, and locating the 


application code. 


4) Creating a configuration file that will tell the Nucleus 


the locations of available RAM memory, initial char- 
acteristics of each system job, and pertinent overall 
system parameters. Each job in the system has an en- 
try in the configuration 
file. The order of the entries 


is the order of initialization of the jobs. 


5) Creating the Root Job by assembling, linking, and 


locating the configuration 
file. 


inter 


LINKED 
& 
lOCATED 
iRMX 86 


CODe 


ASSEMBLED, 


LINKED 
& 
LOCATED 
APPLICATION 


CODE 


DEDICATED 
SYSTEM 
MEMORY 


AVAILABLE 
SYSTEM 
MEMORY 


During development of an EPROM-based 
application 


such as this one, configuration 
is accomplished twice: 
once for the RAM-based development system and once 
for the final EPROM-based 
system. These configura- 


tions are detailed in Appendix C, System Configura- 
tion. In both cases, the Root Job that results from con- 
figuration initializes the system jobs. For development, 
the system job structure is shown in Figure 7. The Root 
Job creates the Debugger Task in the Debugger Job, 
which in turn creates the Terminal Handler Task. The 
Root Job then creates the SUPERVISOR TASK, which 
creates the INPUT TASK, FFT TASK, and OUTPUT 
TASK. The INPUT TASK creates the INTERRUPT 
TASK when necessary. 


Software development is completed on the iSBC 86/l2A 
Single Board Computer 
discussed earlier in this note. 


After application 
code is debugged and ready to be 


placed in EPROM memory, the Debugger Job, which 
contains both the Debugger and the Terminal Handler, 
is removed and replaced with the Terminal 
Handler 


Job, which contains only the Terminal Handler. This 
job structure is shown in Figure 8. The Nucleus system 
calls required only by the Debugger are removed from 
the iRMX 86 Nucleus. The application 
code is not 


changed. 
The 
application 
code 
and 
the 
iRMX 
86 


Nucleus 
is configured 
for the final system, 
put in 


EPROM memory, and tested on the final hardware sys- 
tem. The final Nucleus and application code required 
30.5K bytes of EPROM, allowing room for future code 
changes and some expansion 
within the 32K system 


limit. 


The final application hardware is shown in Figure 14. 
This system contains an iAPX 86/10 CPU, an 8259A 
Programmable 
Interrupt Controller, 
and an 8253 Pro- 


grammable Timer. The three chips form the primary 
hardware requirements for the iRMX 86 Operating Sys- 
tem. The system is assembled from Intel components, 
using standard support circuits and system schematics 
described in Intel documentation. 
The analog sampling 


circuitry is a 12-bit analog to digital converter (ADC) 
and a sample/hold circuit. Both the sample/hold 
circuit 


and the ADC are driven from the on-board local bus. 
The ADC has a conversion time of 35 microseconds, 
limiting the overall cycle to approximately 
39 micro- 
seconds per sample, or a maximum CRT display band- 
width of 12,000 hz. 


The hardware system shown in Figure 14 contains com- 
ponents not specifically required for the final configura- 
tion. The 8255A Programmable 
Peripheral 
Interface 


and the MULTIBUS multi master interface are not nec- 
essary for a system limited to just spectrum analysis and 
display via the CRT. However, the flexibility advan- 
tages of the iRMX 86 Operating System are supported 
by this hardware. For instance, the frequency spectrum 
display is limited by the CRT to a 16-levellogarithmic 
approximation. 
Accuracy could be improved by using 


the programmable peripheral interface to drive a plotter 
or an analog CRT via a digital to analog converter. 
Software drivers for the plotter or CRT could be new 
tasks, interfacing 
to the old tasks through 
the mail- 


boxes. Or, the OUTPUT 
TASK could be simply re- 


placed with a new OUTPUT TASK for the plotter and 
analog CRT. The inclusion of the MULTIBUS interface 
allows this application 
to be integrated 
into a larger 


system of MULTIBUS-compatible 
boards. 
MULTI- 


BUS-compatible memory boards will also aid test and 
debug. Users of hardware components can include these 
modular 
Intel interfaces as required by their applica- 


tion, giving growth and configurability 
in both hard- 


ware and software. 


inter 


Figure 
14. 
Final Hardware 
System 
Block Diagram 


PL/M 
86™ Compiler, 
MCS-86™ Macro Assembler, 


and the MCS-86 Utilities LINK86, LOC86, and OH86. 
The Intel UPP-1O3™ Universal PROM Programmer 
is 


used to convert the final system to PROM memory. 
This broad support 
allows expedient development 
of 


prototype 
and final systems based on the iRMX 86 


Operating System. 


This application 
note discussed general operating sys- 


tem functions, 
the Intel iRMX 86 Operating 
System, 


using the iRMX 86 Operating System on hardware com- 
ponent systems, and an example of an application im- 
plemented in a component 
environment. 
Users of the 


iRMX 86 Operating System are able to simplify applica- 
tion code development 
through 
modularity, 
standard 


interfaces, 
freedom 
from rigid hardware 
restrictions, 


and advanced 
debugging techniques. 
The iRMX 86 


Operating System can be applied to larger systems by 
adding other iRMX 86 layers, making the software in- 
vestment 
beneficial over a wide range of applications. 


Operating systems provide many advantages for hard- 
ware component designs, but all of these benefits can be 
utilized only if the operating system and the develop- 
ment environment are fully supported. 
Intel's support 


for this application begins with an Intel MDS 230 Series 
II Microcomputer 
Development System. The MDS 230 


System 
interfaces 
with 
the 
development 
hardware 


through the iSBC 957A™ Monitor. 
The development 


hardware is an Intel iSBC 86/12A Single Board Com- 
puter, an Intel iSBC 71JTMAnalog Input Board, an Intel 
iSBC 032™ 32K RAM Memory Board, an Intel iSBC 
064TM64K RAM Memory Board, and an Intel iSBC 
660™ System Chassis. Final application hardware is de- 
bugged using Intel's 
ICE-86™ 8086 In-Circuit 
Emu- 


lator. 
Software 
support 
is provided 
by the ISIS-II 


The iRMX 86 Operating Systems and the Intel develop- 
ment tools are valuable only if they translate directly to 
increased productivity and shortened time to market for 
new products. This application has 1567 lines of appli- 
cation code. It was developed, from design to final im- 
plementation, 
in approximately 9 man-weeks of effort. 


This high level of productivity 
was achieved with the 


added benefits of modularity, standardization, 
and ease 


of application growth. 


Intel Corporation 
is committed to both the continued 


integration of higher-level functions into hardware and 
to maintaining 
compatibility 
of present software with 


new hardware. One result of these commitments will be 
the Intel iAPX 86 and iAPX 286 Processors, which will 
be compatible 
with the iRMX 86 Operating 
System. 


Another result will be the placement of the iRMX 86 
Operating 
System Nucleus into hardware. 
This will 


allow custom hardware applications to have higher-level 
functions, simplified development, and decreased chip 
count. Using the iRMX 86 Operating System today will 
give hardware component users a headstart on Intel's 
technological innovation for tomorrow. 
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PL/M-86 
COMPILER 
SUPERVISOR 
TASK 
FOR 
AP 
NOTE 
110, 
OCTOBER 
1980 
ISIS-II 
PL/M-86 
V2.0 
COMPILATION 
OF 
MODULE 
SUPERVISOR 
MODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:superv.OBJ 


COMPILER 
INVOKED 
BY: 
plm8n 
:Fl:superv.p8~ 


Stitle(' 
SUPERVISOR 
TASK 
FOR 
AP 
NOTE 
110, 
OCTOBER 
1980') 


Slarge 
ctebug 
SUPERVISOR 
MODULE: 


do; 
Sinclude(:fl:nuclus.ext) 


SSAVE 
NOLIST 


/************************************************/ 
/* 
The 
six 
mailboxes 
immediately 
following 
will 
*/ 


/* 
form 
all 
of 
the 
inter-task 
communications 
*/ 


/* 
interfaces 
for 
the 
five 
tasks 
that 
run 
in 
*/ 


/* 
this 
system. 
*/ 


/************************************************/ 


090 
1 
declare 
th 
in 
mbx 
token; 


091 
1 
declare 
th-out 
mbx 
token; 


092 
1 
declare 
to 
input 
mbx 
token 
public; 


093 
1 
declare 
to-fft 
mbx 
token 
public; 


094 
1 
declare 
to-output 
mbx 
token 
public; 
095 
1 
declare 
to-supervIsor 
mbx 
token 
public; 
- 
- 


0% 
1 
declare 
return 
th 
in 
mbx 
token; 


097 
1 
declare 
return -th-out 
mbx 
token; 


098 
1 
declare 
dumrny_mbx- 
token; 


099 
1 
declare 
frame 
segment 
one 
token; 


100 
1 
declare 
frame -segment -two 
token; 


101 
1 
declare 
frame -segment -three 
token; 
102 
1 
declare 
th 
in-segment -token 
token; 


103 
1 
declare 
th-out 
segment 
token 
token; 
- 
- 
- 


104 
1 
declare 
general 
index 
hyte; 


105 
1 
declare 
number 
of 
fft 
data 
segments 
byte; 
- 


106 
1 
declare 
insert 
text 
pointer 
pointer; 
- 
- 


107 
1 
declare 
abort 
flag 
Imrd; 


108 
1 
declare 
status 
wo rd; 


109 
1 
declare 
segment 
deleted 
tally 
word; 
110 
1 
declare 
text 
length 
word; 
- 


111 
1 
declare 
root 
job 
token 
token; 


112 
1 
declare 
input 
task 
token 
token; 


113 
1 
declare 
fft 
task 
token 
token; 


114 
1 
declare 
output 
task 
token 
token; 
- 
- 


115 
1 
declare 
parameters 
structure( 
actual 
samples 
word, 
- 


116 
117 
118 
119 
120 
121 
122 
123 
124 
12S 
126 
127 
128 
129 
130 
131 
132 
133 
134 


136 
137 


139 
140 


declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 


actual 
interval 
frequency 
answer(S) 
actual 
frames 
to 
average 
frames-to 
average 
answer(S) 
continuous 
flag 
- 
continuous=flag_answer(S) 


word, 
byte, 
word, 
byte, 
word, 
byte) ; 


abort 
asci i 9 
carriage 
return 
forever 
- 
line 
feed 
new 
tft 
run 
no 
abort 
no 
response 
requested 
null 
- 
queue 
fifo 
queue-priori 
ty 
root job 
run 
continuous 
size 
l20_bytes 
space 
supervisor 
job 
th 
read 
- 
th-write 
waTt 
forever 


literally'OFFH'; 
literally'039H'; 
literally'OOH'; 
literally 
'while 
1'; 


literally'OAH'; 
literally'OFFH'; 
li terally 
'DOH'; 


literally'OOH'; 
literally'OOH'; 
literally'OOH'; 
literally'OlH'; 
literally'03H'; 
literally'OFFFFH'; 
literally 
'120'; 


literally'20H'; 
literally 
'OOR'; 


literally 
'OIR'; 


literally 
'OSH'; 


literally'OFFFFH'; 


/* 
The 
following 
declaration 
sets 
the 
characters 
*/ 
/* 
to 
send 
the 
cursor 
home 
at 
the 
beginning 
of 
*/ 
/* each 
message 
to 
the 
display 
screen. 
The 
*/ 
/* 
seqeunce 
is 
tilde, 
DC2 
(Hazeltine)). 
*/ 


declare 
declare 
frame 
pointer 
frame-pointer 
values 
offset 
word, 
base 
word) 
at 
(@frame_pointer); 


pointer; 
structure( 


declare 
frame 
based 
frame 
pointer 
samples 
per 
frame- 
sample 
Tnterval 
frames-to 
average 
continuous 
flag 
this 
frame-number 
number 
samples 
missed 
sample-po 
inter- 
reset 
flag 
sample 
(2S6) 


structure( 
word, 
word, 
word, 
word, 
word, 
word, 
word, 
word, 
integer) 
; 


declare 
th 
in 
segment 
pointer 
pointer; 


declare 
th-in-segment-pointer 
values 
structure( 


offset 
word, 
- 
- 
base 
word) 
at 
(@th_in_segment_pointer); 


inter 


142 
143 


th 
in 
segment 
structure 
( 
function 
count 
exception 
code 
actual 
message 
(112) 


word, 
word, 
word, 
wo rd , 
byte) ; 


declare 
th 
out 
segment 
pointer 
pointer; 
declare 
th-out-segment-pointer 
values 
structure( 
offset-word, 
- 
- 
base 
word) 
at 
(@th_out_segment_pointer); 


th 
out 
segment 
structure 
( 
function 
count 
exception 
code 
actual 
- 
home 
chars(2) 
line-index(24) 
message 
(84) 


word , 
word, 
word, 
word, 
byte, 
byte, 
byte) ; 


declare 
frequency 
question(*) 
byte 
data 
('Please' 
, enter 
the 
highest 
frequency 
in 
Hz 
(120, 


, 
I) 00, 
1200, 
11000, 
OR 
17.000) : ') ; 


declare 
frequency 
answers 
data(*) 
byte 
data 
(OSH, 
03H,03H,04H,04H,05H,OH, 


I 
120 
600 
1200 
1)00012000 
42H,OFH, 
00DH,03H, 
OR7H,01R, 
4EH,00H, 
027H,00H, 
OOH,OOOH); 


declare 
average 
question(*) 
byte 
data 
('Please' 


, enter-the 
number 
of 
frames 
to 
average' 
(1, 
2, 
4, 
8, 
15, 
OR 
32) :'); 


declare 
average 
answers 
data(*) 
byte 
data 
(OI1H, 
01H,01H~01H,01H~02H,02H, 
, 
1 
2 
4 
8 
16 
32', 
OlH,OOH, 
02H,00H, 
04H,OOH, 
08H,OOH, 
10H,00H, 
20H,nOH); 


declare 
continuous 
question(*) 
byte 
data 
('Please' 


, enter' 
'I" 
for 
one 
sample 
run 
or 
"C' 
" 
, for 
continuous 
running:'); 


declare 
continuous 
answers 
data(*) 
byte 
data 
(03H, 


OIH,OIH,OIH,OOH,OOH,OOH, 
, 
1 
C 
c 
OOH,OOH, 
OFFH,OFFH, 
OFFH,OFFH, 
OOH,OOH,OOH,OOH, 
DOH,OOH); 


declare 
reject 
message(*) 
byte 
data 
('I 
cannot' 
, accept 
your 
answer. 
PLEASE 
TRY 
AGAIN.'); 


declare 
status 
line one(*) 
byte data 
('Current' 


, settTngs are 
the following: 
frequency' 
, range 0 to 
HZ,'); 


declare 
status 
line two(*) byte data 
(' 
, frames 
to-average 
per output 
display,' 


, 
and. 
') ; 


declare 
continuous 
runs(*) byte data 
('continuous 
runs.'); 


declare 
single 
run(*) byte data 
('a single 
run. 
'); 


declare 
go ahead question(*) 
byte data 
('If' 


'these settings 
are correct, 
enter' 
'G" 


'to begin 
running.'); 


declare 
header 
line one(*) 
byte data 
(' INTEL' 


, APNOTE 
110--THE 
iRMX 86 OPERATING 
SYSTEM' 


, AND iAPX 
86 COMPONENT 
DESIGNS.'); 


/************************************************/ 
/* The 
following 
three procedure 
declarations 
*/ 


/* 
link the tasks outside 
the SUPERVISOR 
MODULE 
*/ 


/* with 
the supervisor 
task. 
*/ 


/************************************************/ 


158 
1 
INPUT TASK: 
PROCEDURE 
EXTERNAL; 
159 
? 
END INPUT_TASK; 


lliO 
1 
FFT TASK: 
PROCEDURE 
EXTERNAL; 
161 
2 
END FFT_TASK; 


152 
1 
OUTPUT 
TASK: 
PROCEDURE 
EXTERNAL; 
163 
2 
END OUTPUT_TASK; 


/***********************************************/ 
/***********************************************/ 
/** The 
following 
five procedures 
are general 
**/ 


/** utility 
procedures 
called 
by the primary 
**/ 


/** working 
procedures. 
**/ 


/***********************************************/ 
/***********************************************/ 


/********************************************/ 
/* Blank 
line just fills the message 
buffer 
*/ 


/* with blank 
characters. 
*/ 


/********************************************/ 


inter 


16:'; 
1:';7 


175 
1 


176 
2 
177 
2 
178 
2 


179 
2 


180 
2 
181 
3 


182 
3 


183 
2 
184 
3 


185 
3 
186 
3 


187 
2 


188 
2 


do 
blank 
line 
index 
= 
0 to 
78; 
th_out_segment.message 
(blank_line 
index) 


= 
space; 


/*****************************************/ 
/* 
DISPLAY 
LINE 
sends 
the 
message 
to 
the 
*/ 


/* 
terminal 
handler 
output 
mailbox 
and 
*/ 
/* 
waits 
for 
the 
segment 
to 
be 
returned. 
*/ 


/*****************************************/ 


call 
rq$send$message 
(th 
out 
mbx, 
th-out-segment 
token, 
return-th 
out 
mbx, 
~status); 


th_out 
segment_token 
rq$receive~message 
(return 
th 
out 
mbx, 
wait 
forever,-@dummy 
mbx, 


@status;) 
- 


/************************************************/ 
/* INSERT 
TEXT 
fills 
the 
output 
message 
segment 
*/ 
/* with 
the 
chosen 
message 
and 
pads 
the 
rest 
of 
*/ 
/* the 
line 
with 
blanks. 
*/ 
/************************************************/ 


declare 
declare 
declare 


text 
pointer 
pointer; 
how_many 
word; 
dummy 
based 
text 
pointer 
structure( 


entries(80) 
byte); 
insert 
text 
index 
word; 


do 
insert 
text 
index 
= 
0 to 
(how 
many 
- 
1); 


th 
out 
segment.message 
(insert 
text 
index) 


- 
dummy.entries 
(insert 
text=index); 


end; 


do 
while 
insert 
text 
index 
< 
79; 
th 
out 
segment.message 
(insert 
text_index) 


= 
space; 
insert 
text 
index 
insert 
text 
index 
+ 
1; 


end; 


189 
1 


190 
2 
191 
2 


192 
2 
193 
2 
194 
3 


195 
3 


196 
2 
197 
3 


198 
3 


199 
2 


201 
202 
203 
204 
205 


/**********************************************/ 
/* Move down 
line puts 
the required 
number 
of */ 
/* line-feed-characters 
in the first ~th 
*/ 
/* through 
29th character 
of the output 
*/ 


/* message. 
Each line 
is displayed 
on the 
*/ 
/* screen 
in its proper 
location. 
This allows 
*/ 
/* multiple 
tasks 
to access 
the screen 
*/ 
/* without 
having 
to blank 
the line each 
*/ 
/* time. This technique 
assumes 
each message 
*/ 
/* sends 
the cursor home 
each time. 
*/ 
/* **.***********~*** *** ******* *** *** **** *** *** ***/ 


declare 
skip lines 


declare 
move-down 
line 
index 
word; 
word; 


if skip lines> 
0 then 
do move down 
line index = 0 
th out segment.line 
~ndex 
- 
line feed; 
- 
end; . 


to 
(skip lines - 1); 


(move_down 
line_index) 


do mo~e down 
line 
index = skip lines to 23; 


th out segment~line 
index 
(move down 
line 
index) 
- null; . 
- 
- 
- 
- 


/***********************************************/ 
/* SEND REJECT 
MESSAGE 
is called 
by INPUT 
*/ 
/* PARAMETERS.- 
It just sends a reject message 
*/ 
/* to the CRT to inform the user that the 
*/ 
/*answer 
the user gave was not valid. 
*/ 
/***********************************************/ 


call move down 
line 
(21); 
text length 
= size(reject_message); 
insert 
text pointer 
= @reject message; 


call 
insert-text 
(insert text pointer, 
text_length); 


call display_line; 
- 


/*************************************************/ 
/*************************************************/ 
/** The 
following 
procedures 
are the primary 
**/ 
/** working 
procedures 
called 
by the supervisor 
**/ 
/** procedure 
and its called 
procedures. 
**/ 
/*************************************************/ 
/*************************************************/ 


intJ 


209 
210 


211 
212 
213 


215 
216 


217 
218 
219 


221 
222 
223 


/************************************************/ 
/* 
PURGE 
MAILBOX 
removes 
all 
tokens 
from 
*/ 


/* 
a mailbox. 
The 
purpose 
is 
to 
remove 
segments 
*/ 
/* 
waiting 
for 
processing 
by 
one 
of 
the 
tasks 
*/ 


/* 
if 
the 
operator 
has 
specified 
an 
abort 
*/ 


/* 
request. 
If 
the 
segment 
deletion 
was 
*/ 


/* 
successful, 
PURGE 
MAILBOX 
updates 
the 
*/ 


/* 
segment 
deleted 
tally. 
*/ 


/************************************************/ 


declare 
mailbox_to_purge 


declare 
for 
110 
milliseconds 
declare 
message_received 
literally'OBH'; 


literally'OH'; 


declare 
contents 
token 
declare 
purge 
dummy 
mbx 
declare 
purge=status 


token; 
token; 
token; 


do 
while 
purge 
status 
= message 
received; 
contents 
token 
= 
rqSreceiveSmessage 
(mailbox 
to 
purge, 
for 
110 
milliseconds, 


@purge_dummy_mbx, 
@purge_status); 


if 
purge 
status 
= message 
received 
then 
do; 
- 
- 
call 
rqSdeleteSsegment 
(contents 
token, 
@purge_status); 


segment 
deleted 
tally 
= 
- 
segment 
deleted 
tally 
+ 
1; 


purge 
status 
message=received; 
end; 
- 


/***********************************************/ 
/* MONITOR 
MAILBOXES 
polls 
the 
*/ 
/* 
return 
th 
in 
mailbox 
and 
the 
*/ 
/* to 
SUperVISOr 
mailbox 
for 
messages. 
The 
*/ 
/* messages 
will-be 
abort 
(from 
the 
operator), 
*/ 
/* 
and 
FFT 
done 
or 
OUTPUT 
done 
if 
the 
runs 
are 
*/ 
/* 
not 
continuous. 
If 
the 
runs 
are 
not 
*/ 
/* continuous 
and 
an 
FFT 
done 
message 
is 
*/ 
/* 
received, 
MONITOR 
MAILBOXES 
will 
initialize 
*/ 
/* the 
OUTPUT 
task. 
- 
*/ 
/***********************************************/ 


inter 


226 
2 
declare 
cannot 
wait 
Ii terally 
'OOH' ; 
227 
2 
declare 
done 
literally 
,OFFH' ; 


228 
2 
declare 
for 
400 
mill iseconds 
1 iterally 
,28H' ; 
229 
2 
declare 
-received 
1 iterally 
'DOH' ; 
message 


230 
2 
declare 
not 
done 
1 iterally 
'OOH' ; 


231 
2 
declare 
moni.tor 
dummy_ mbx 
token; 


232 
2 
declare 
monitor -token 
token; 


233 
2 
declare 
monitor 
status 
token; 


234 
2 
declare 
done 
flag 
byte; 
235 
2 
declare 
monitor 
index 
wo rd; 


236 
2 
done 
flag 
not 
done; 
- 
- 


237 
2 
segment 
deleted 
tally 
= 
0; 
238 
2 
call 
rq$sendSmessage 
(th 
in mbx, 
th 
in 
segment 
to'ken, 
return 
th 
in mbx~ 
@status) 
; 
- - - 


239 
2 


240 
3 


241 
3 


242 
3 


243 
4 


244 
4 


245 
4 
240 
4 


247 
4 


248 
4 


249 
4 
250 
4 
251 
4 


252 
3 
253 
3 
254 
4 


255 
4 
256 
4 
257 
5 


258 
5 


do 
while 
done 
flag 
= 
not 
done; 


/* 
Check 
for 
operator 
input 
here. 
*/ 
monitor 
token 
= 
rq$receiveSmessage 
(return 
th 
in 
mbx, 
for 
400 
milliseconds, 


@monitor 
dummy 
mbx, 
0monitor 
status); 


if 
monitor 
status 
= message 
received 
then 


do 
while-segment 
deleted 
tally 
< 
number 
of 
fft-data 
segments; 
call 
purge 
mailbox 
(to 
fft 
mbx); 
if 
segment-deleted 
tally 
<- 
number 
of 
fft 
data 
segments 
then 
call 
purge 
mailbox 
(to 
input 
mbx); 


if 
segment 
deleted 
tally < 
- 
number 
of 
fft 
data 
segments 
then 
call 
purge 
mailbox 
(to 
supervisor 
mbx); 


if 
segment 
deleted 
tally < 
- 
number 
or 
fft 
data 
segments 
then 
call 
purge 
maTlbox-(to 
output 
mbx); 
done 
flag 
= done; 
- 
- 
end; 
- 


if 
clone fl ag 
do; 
monitor 
token 
= 
rq$receiveSmessage 
(to supervisor 
mbx, 
for 
400 
milliseconds, 


@monitor 
dummy 
mbx, 
~monitor 
status); 


if 
monitor 
status 
~ 
message 
receTved 
then 


do; 
- 
- 


if 
parameters.continuous 
flag 
run 
continuous 
then 
- 
call 
rqSsend$message 
(to 
input 
mbx, 
monitor 
token, 
no-response 
requested~ 
@monitor_statuS) 
; 


inter 


259 
260 


264 
265 
266 
267 


269 
1 


270 
2 
271 
2 


272 
2 


273 
2 


274 
2 


275 
2 
276 
2 
277 
2 


278 
2 


283 
284 


do; 
call 
rq$delete$segment 
(monitor 
token, 
Elmonitor 
status); 


segment 
deleted 
tally 
- 
= 
segment 
deleted 
tally 
+ 
1; 


if 
segment 
deleted 
tally 
= 
number-of 
fft 
data 
segments 


then 
done 
flag 
~ 
done; 
end; 
- 
end; 
end; 


/*********************************************~**/ 
/* SET 
SEGMENT 
initializes 
the 
common 
parameter 
*/ 


/* 
areas 
of 
the 
segment. 
The 
pointer 
to 
the 
*/ 
/* 
proper 
segment 
is 
set 
up 
by 
*/ 


/* INITIALIZE 
SEGMENTS. 
*/ 


/************************************************/ 


frame.samples 
per 
frame 
= 
128; 
frame.sample 
Tnterval 
-= parameters.actual 
interval; 
frame. frames 
to 
average 
= parameters.actual 
frames 
to 
average; 


frame.continuous 
flag 
= 
parameters.contTnuous 
flag; 


frame.this 
frame 
number 
frame.number 
samples 
missed 
frame.sample-pointer- 
frame. reset_flag 


DOH; 
DOH; 
OOH; 
OOH; 


/************************************************/ 
/* 
INITIALIZE 
SEGMENTS 
creates 
the 
three 
FFT 
*/ 


/* data 
segments 
and 
calls 
SET 
SEGMENT 
for 
each 
*/ 
/* segment 
to 
initialize 
the 
common 
parameter 
*/ 
/* 
areas 
of 
the 
segments. 
*/ 
/************************************************/ 


frame 
segment 
one 
= 
rq$create$segment 
- 
-(size 
528 
bytes, 
~status); 


frame 
pointer 
values.base 
frame 
segment 
one; 
call 
set_segment; 
-- 


285 
286 
287 


288 
289 
290 


291 
292 
293 
294 


296 
297 
298 


300 
301 
302 


frame.reset 
flag 
number 
of 
fft 
data 
segments 
call 
rqSsend$message 
(to 
input 
mbx, 
frame 
segment 
one, 


no=response_requested, 
@status); 


new 
fft 
run; 
1; - 
- 


if 
parameters.actual 
frames 
to 
average> 
1 then 


do' 
- 
- 
frame 
segment 
two = 
rqScreateSsegment 
- 
(size 
528 
bytes, 
@status); 


frame 
pointer 
values.base 
= 
frame 
segment 
two; 


call 
set 
segment; 
-- 


number 
of 
fft 
data 
segments 
2; 
call 
rqSsendSmessage 
(to 
input 
mbx, 
frame 
segment 
two, 


no=response_requested, 
@status); 


if 
parameters.actual 
frames 
to_average> 
2 then 


do; 
frame 
segment 
three 
= 
rq$create$segment 


- 
(size 
528 
bytes, 
@status); 


frame 
pointer 
values.hase 
- 
- 
= 
frame_segment_three; 


call 
set 
segment; 


number 
of 
fft 
data 
segments 
= 
3; 
call 
rq$sendSmessage 
(to 
input 
mbx, 
frame 
segment 
three, 


no=response_requested, 
@status); 


/***********************************************/ 
/* 
INPUT 
PARAMETERS 
contains 
three 
procedures: 
*/ 
/* set 
question 
pointers, 
get 
answer, 
*/ 
/* 
and 
verify 
answers. 
The 
INPUT 
PARAMETERS 
*/ 


/* 
loop 
consists 
of 
calls 
to 
these 
three 
*/ 
/* 
procedures 
and, 
as 
usual, 
exists 
at 
the 
end 
*/ 


/* of 
the 
procedure. 
*/ 
/***********************************************/ 


305 
1 
INPUT 
PARAMETERS: 
PROCEDURE; 
- 


30n 
2 
declare 
actual 
pointer 
pointer; 
- 
307 
2 
declare 
answer 
pointer 
pointer; 


308 
2 
declare 
-display 
pointer 
pointer; 
answer 


309 
2 
declare 
question 
pointer 
pointer; 
- 


310 
2 
declare 
answer 
actual 
value 
based 
actual 
pointer 
word; 
- 


311 
2 
declare 
answer 
overlay 
based 
- answer 
pointer 
structure( 


number 
of 
answers 
byte, 


313 
314 
315 
3lFi 
317 
318 
319 
3'20 


321 
322 
323 
324 
325 
32/'j 
327 
328 
329 


332 
333 
334 
335 
336 
337 


339 
340 
341 
342 
343 


34fi 
347 
348 
349 
350 


length 
of 
answer(6) 
values-to-match(30) 
really=are(l)) 


byte, 
byte, 
word) ; 


declare 
answer 
display 
based 
- 
answer 
display 
pointer 
structure( 


characters(S) 
byte); 


declare 
answer 
byte 
index 
declare 
answer-index 
declare 
answer 
match 
declare 
byte 
match 
declare 
input 
byte 
index 
declare 
output 
byte 
index 
declare 
question 
number 
declare 
stop_byte 


declare 
ascii 
small 
g 
declare 
ascii-capital 
G 
declare 
average 
entry-point 
declare 
continuous 
entry 
point 
declare 
frequency 
entry 
point 
declare 
match 
- 
- 
declare 
no 
match 
declare 
not 
negative 
declare 
nothing_returned 


literally 
'0/'j7H'; 


literally 
'047H'; 


literally 
'0'; 


literally 
'48'; 


literally 
'58'; 


literally 
'OFFH'; 


1 itera 11 y 
'0OH '; 


literally 
,< 
255'; 


literally 
'DOH'; 


byte; 
byte; 
byte; 
byte; 
byte; 
byte; 
byte; 
byte; 


set_question_pointers: 
procedure; 


do 
case 
question_number; 


do; 
text 
length 
size 
(frequency 
question); 


question 
pointer 
= 
@frequency 
question; 


answer 
pointer 
= 
~frequency 
answers 
data; 


actual-pointer 
= 
@parameters.actual-interval; 


answer-display 
pointer 
- 
- 
= 
@parameters.frequency_answer; 


do; 
text 
length 
size 
(average 
question); 


question 
pointer 
= 
@average 
question; 
answer 
pointer 
= 
eaverage 
answers 
data; 


actual-pointer 
-- 
-= 
@parameters.actual 
frames 
to 
average; 


answer 
display 
pointer 
- 
- 
- 
@parameters.frames_to_average_answer; 


do; 
text 
length 
size 
(continuous 
question); 


question 
pointer 
= 
@continuous 
question; 


answer 
pointer 
@continuous 
answers 
data; 


actual=pointer 
@parameters~continuous_flag; 


inter 


35n 
357 
358 


359 
360 
3nl 


367 
3n8 


352 
353 


answer 
display 
pointer 
- 
@parameters.continuous_flag_answer; 


end; 
end; 


/* 
First 
display 
the 
question 
to 
be 
answered 
*/ 


/* 
by 
the 
operator. 
*/ 


call 
insert 
text 
(question_pointer, 
text 
length); 


call 
move 
down 
line 
(19); 
call 
dispTay_lTne; 


/* 
Then 
blank 
the 
line 
below 
for 
an 
answer 
line. 
*/ 


call 
blank 
line; 
call 
move 
down 
line 
(20); 
call 
dispYay_lTne; 


/* Now 
wait 
for 
a 
response 
from 
the 
operator. 
*/ 


call 
rqSsendSmessage 
(th 
in 
mbx, 
th 
in 
segment 
token, 


return 
th 
in mbx~ 
@status) 
; 


th 
in 
segment 
token 
= 
rqSreceTveSmessage 
- 
(return 
th 
in 
mbx, 
wait 
forever, 


@dummy-mbx, 
@status); 
- 
th 
in 
segment 
pointer 
values.base 
- 
- 
th_Tn_segment_token; 


/* If 
there 
is 
no 
message 
returned 
then 
send 
*/ 
/* 
a 
rej ec t message. 
*/ 


if 
th 
in 
segment.actual 
= 
nothing_returnen 
then 
call 
send 
reject_message; 


/* Otherwise 
it 
is 
time 
to 
check 
the 
response 
*/ 
/* against 
the 
possible 
answers. 
*/ 


else 
do; 
answer_match 
= 
no_match; 


answer 
index 
= 
answer_overlay.number_of_answers; 


/* 
Start 
a 
loop 
to 
check 
all 
of 
the 
*/ 


/* possible 
answers. 
*/ 


380 
381 
382 


383 
384 
385 


3811 
387 


do 
while 
(answer 
match 
no 
match) 
and 


(answer-index 
> 0); 


/* Set 
the 
starting 
point 
for 
the 
*/ 


/* 
byte 
by 
byte 
compare. 
*/ 


/~ 
Set 
the 
stopping 
point 
for 
*/ 
/* 
the 
compare. 
*/ 


stop_byte 
= 
answer 
byte 
index 
- 
answer 
overlaY.length 
of 
answer 


(answer 
index 
- 
1); 
- 


/* Start 
with 
a 
"match" 
so 
we 
can 
*/ 


/* 
check 
until 
"no 
match" 
occurs. 
*/ 


/* Set 
starting 
point 
at 
the 
right 
end 
*/ 


/* 
of 
the 
input 
data 
(allows 
us 
to 
*/ 


/* 
ignore 
leading 
blanks 
and 
the 
*/ 


/* ending 
carriage 
return). 
*/ 


input_byte_index 
= 
th_in 
segment.actual-2; 


/* 
Scan 
the 
bytes 
until 
all 
pertinent 
*/ 


/* 
ones 
are 
checked 
or 
a 
"no 
match" 
*/ 
/* occurs. 
*/ 


do 
while 
(byte 
match 
= match) 
and 
(answer 
byte 
index 
> 
stop 
byte); 


if 
(input 
byte-index 
not 
negative) 


then 
do;- 
- 
if 
th 
in 
segment.message 
(input-byte 
index) 
= 
answer 
overlay.values 
to 
match 


(answer 
byte 
index)- 
- 
then 
byte 
match 
match; 


else 
byte-match 
no_match; 


end; 
- 
else 
byte 
match 
= 
no_match; 


answer 
byte 
index 
input 
byte 
Tndex 
end; 
- 
- 


answer 
byte 
index-I; 


input_byte_Tndex 
-1; 


/* A 
"match" 
at 
this 
point 
means 
ALL 
*/ 


/* 
bytes 
matched. 
*/ 


if 
byte 
match 
= match 
then 
do; 


inter 


390 
391 


392 
393 


397 
398 
399 
400 


401 
402 


405 
406 
407 


answer 
actual 
value 


", 
~ answer 
overlay.really 
are 


(answer index - 1); 
- 
answer_match 
= match; 


/~ Insert displayable 
values 
for */ 


/* later display. 
*/ 


answer 
byte 
index = 4; 
input_byte Tndex 
= 
(answer index*5)-1; 


do while 
answer 
byte 
index not negative; 


answer display.characters- 
-(answer 
byte 
index) 
= answer 
overlay~values 
to match 


(input byte 
index);- 


input byte 
index 
- 
= Tnput-byte 
index - 1; 


answer 
byte 
index 
answer=byte_index 
- 1; 


/* We got a match, 
so be sure the 
*/ 


/* 
reject message 
line is blanked. 
*/ 


call move down 'line (21); 
call blank 
line; 
call display_line; 
er:!d; 


/* If no match, 
then let's compare 
the 
*/ 


/* input with 
the next possible 
answer. 
*/ 


else answer 
index = answer 
index - 1; 


end; 
/* If we got a match, 
then we can move on */ 


/* to the next question. 
*/ 


if answer match 
= match 
then question_number 
= question_number 
+ 1; 


/* Otherwise 
we have 
to check 
for an 
*/ 


/* abort 
request of 
'99'. 
*/ 


else 
do; 
input byte 
index = th in segment.~ctual-2; 


if (th in segment.message(input 
byte 
index) 


- 
~ ascii 
9) 
-- 


and' 


(th in_segment.message 
(input byte 
index - 


ascii 
9) then 


408 
409 
410 
411 
412 
413 


414 
415 
416 


419 
420 


421 
422 
423 


425 
426 


427 
42R 


429 
430 


/* Abort 
requests 
are valid, 
so blank 
*/ 


/* the reject message 
line and reset 
*/ 


/* the question 
number 
so we start 
*/ 


/* asking 
allover. 
*/ 


do; 
question 
number 
= 
1; 
call move down 
line 
(21); 
call blank 
line; 
call display 
line; 
end; 
- 
else 


/* But if nothing 
matched 
and the 
*/ 


/* answer 
was not an abort 
request, 
*/ 


/* then we have 
to ask the operator 
*/ 


/* to try again on this question. 
*/ 


call 
send 
reject_message; 
end; 
end; 


text 
length 
size 
(status line one); 


call-insert 
text 
(@status line_one, text_Tength); 


input byte 
index 
stop byte - 
do output 
byte 
index 
~ 
frequency 
entry point 
to stop byte; 


th oue segment.message 
(output 
byte 
index) = 


parameters.frequency 
answer 
(Tnput-byte 
index); 


input byte 
index 
= Tnput 
byte 
index + 1; 
end; 
- 
- 
- 
- 


0; 
frequency_entry 
point + 4; 


call move down 
line(19); 
call dispTay_lTne; 


/* We have 
sent the first line, now 
it is time */ 


/* to get the second 
line. 
*/ 


text length 
= size 
(status line two); 


call-insert 
text 
(@status_line_two, 
text_length); 


inter 


431 
432 
433 


435 
436 


437 
438 
439 


442 
443 


44/i 
447 


448 
449 


450 
451 
452 
453 


45<1 
455 
45'5 


input byte 
index 
stop byte 
do output 
byte 
index 
~ average 
entry point 
to stop byte; 
th out segment.message 
(output byte-index) 


parameters.frames 
to average-answer 
(input byte 
index); 
- 
input byte-index 
input byte 
index + 1; 


end; 
- 
- 
- 
- 


0; 
average_entry 
point + 4; 


/* The continuous 
answer 
is different--we 
have */ 
/* to decide 
if we have continuous 
runs or 
*/ 
/* single 
runs, and insert 
those words 
in the 
*/ 


/* display 
line. 
*/ 


input byte 
index 
= 0; 
stop byte - 
= continuous 
entry point + 15; 
if parameters.continuous 
flag 
run continuous 


then 
- 
do output 
byte 
index 
~ continuous 
entry point 
to stop byte; 


th out segment.message 
(output byte 
index) 


contTnuous 
runs 
(input byte Tndex); 
input byte 
index 
input byte 
index + 1; 


end; 
- 
- 
- 
- 
else 
do output 
byte 
index 
~ continuous 
entry point 
to stop byte; 


th out segment.message 
(output byte 
index) 


singTe 
run 
(input byte 
index); 
- 
input byte 
index 
=-input 
byt~ 
index + 1; 
end; 
-. 
- 
. - 
- 


/* Then 
send the message 
and wait 
for a response */ 


/* 
from the operator. 
*/ 


call move down 
line(iO); 
call dispTay_lTne; 


text length = size 
(go ahead question); 
call 
insert text 
(@go ahead 
question, 
text length); 


call move down 
line 
(21); 
- 
call dispTay_1Tne; 


call blank line; 
call move down 
line(22); 
call dispTay_lTne; 


call 
rq$send$message 
(th in mbx, 
th in segment 
token, 
return 
th in mbx~ 
@status) ; 
th in segment 
token - 
- 
- 
- 
~ 
rq$receive$message 


inter 


464 
465 
466 


469 
470 
471 
472 
473 
474 
475 
476 
477 


478 
479 
480 


(return 
th 
in 
mbx, 
wait 
forever, 


@dummy-mbx, 
@status); 
- 
th 
in 
segment 
pointer 
values.base 
- 
~ 
th 
in 
segment 
token; 


input_byte 
index 
= 
th 
in_segment.actual 
- 
2; 


/* Check 
for 
a 
"g" 
or 
"G" 
(we 
aren't 
fussy). 
If */ 


/* 
we 
got 
it, 
let's 
quit 
asking 
the 
selection 
*/ 


/* 
questions 
and 
go. 
If 
not, 
we 
have 
to 
start 
*/ 
/* 
at 
question 
1 again 
rather 
than 
try 
to 
find 
*/ 
/* 
out 
which 
of 
his 
or 
her 
answers 
wasn't 
*/ 


/* acceptable. 
*/ 


if 
(th 
in 
segment.message 
(input 
byte 
index) 


= 
ascii 
small 
gT 
or 
- 
(th 
in 
segment.message 
(input 
byte 
index) 


- 
- 
= 
ascii 
capital-G) 
then; 
else 
question_number 
=-0; 
- 


call 
blank 
line; 
call 
move 
down 
line 
(21); 
call 
display_lTne; 


/* 
* 
* 
* 
* * * * * * * * * * * * * * * * * * * * */ 


/* As 
usual, 
the 
actual 
INPUT 
PARAMETERS 
control 
*/ 


/* loop 
is 
at 
the 
end. 
*/ 
/* * * * * * * * * * * * * * * * * * * * * * * * */ 


/* All 
we 
do 
is 
get 
the 
next 
question, 
ask 
the 
*/ 


/* 
question 
until 
it 
is 
answered 
successfully, 
*/ 


/* ask 
all 
of 
the 
questions, 
then 
check 
all 
of 
*/ 
/* the 
answers. 
If 
the 
operator 
doesn't 
like 
*/ 


/* 
the 
set 
of 
answers, 
we 
loop 
through 
them 
*/ 


/* again. 
First 
we 
make 
sure 
the 
reject 
mess~ge 
*/ 


/* 
line 
and 
other 
pertinent 
lines 
start 
out 
*/ 


/* blanked. 
*/ 


call 
blank 
line; 
call 
move 
down 
line 
(18); 
call 
display 
ITne; 
call 
move 
down 
line 
(21); 
call 
display 
ITne; 
call 
move 
down 
line 
(22); 
call 
display 
ITne; 
call 
move 
down 
line 
(23); 
call 
display_lTne; 


input_loop: 
do 
while 
question 
number 
< 
3; 
call 
set 
question 
pointers; 
call 
get=answer; 


inter 


482 
483 


48fi 
1 


487 
2 
488 
2 
489 
2 
490 
2 
491 
2 
492 
2 
493 
2 
494 
2 


495 
2 


call verify 
answers; 
if question=number 
= 
0 then goto 
input_loop; 


/************************************************/ 
/* INITIALIZE 
TASKS 
initializes 
the INPUT TASK 
*/ 


/* and the FFT TASK. 
If the FFT runs are to be 
*/ 


/* continuous, 
INITIALIZE 
TASK also 
initializes 
*/ 


/* the OUTPUT 
TASK. 
If the runs are not 
*/ 
/* continuous, 
the OUTPUT 
TASK 
is initialized 
*/ 


/* by MONITOR 
MAILBOXES. 
*/ 


/***********************************************/ 


declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 


hardware 
interrupt 
level 
3 
no data segment 
- 
nucleus-allocated 
stack 
software 
priority-level 
~7 
software-priority-level 
130 
software-priority-level-131 
stack size 512 
- 
task_flags- 


literally 
'038H'; 


literally'OOH'; 
literally'OOH'; 
literally 
'{)7'; 


literally 
'130'; 


literally 
'131'; 


literally 
'512'; 


literally'OOH'; 


input task token 
rqScreate$task 
- 
(software priority 
level 67, @input 
task, 


no data segment, 
nucleus 
allocatea-stack, 


stack_sTze_512, 
task_flags, 
@status); 


call 
rqScatalog$object 
(supervisor 
job, 
input task token, 
@(lO,'INPUT 
TASK'), 
@status); 


fft task token 
= rq$createStask 
(software priority 
level 
131, @fft task, 


no data segment, 
nucleus 
allocated 
stack, 


stack_sTze_512, 
task 
flags, @status); 


call 
rq$catalogSobject 
(supervisor 
job, fft task token, 
@(8,'FFT 
TASK'), 
@status); 


output_task 
token 
= rqScreateStask 
(software priority 
level 
130, ~output 
task, 


no data segment, 
nucleus 
allocated 
stack, 


stack_sTze_512, 
task 
flags, ~status); 


call 
rq$catalog$object 
(supervisor 
job, output 
task token, 
@(11,'OUTPUT 
TASK'), 
@status); 


inter 


502 
1 


503 
2 


504 
2 
505 
2 
506 
2 


507 
2 
508 
2 
509 
2 
510 
2 
511 
2 


512 
2 
513 
2 
514 
3 
515 
3 
516 
3 


517 
2 


/************************************************/ 
/* 
Initial 
screen displays 
the initial 
two 
*/ 
/* lines on the screen 
and sends blank 
lines 
*/ 
/* for all the other 
lines of the first screen. 
*/ 
/************************************************/ 


call move down 
line(O); 


call blank 
line; 


call display_line; 


call move down 
line(l); 
text length = size (header line one)'; 
insert text pointer 
= @header line 
one; 
call 
insert-text 
(insert text-pointer, 
text length); 


call display_line; 
-- 


call blank 
line; 
do 
initial-screen 
index = 
2 to 23; 
call mo~e down-lin~ 
(initial~screen_index); 


call display 
lTne; 
end; 
- 


/*****************************************/ 
/* 
INITIALIZE 
BUFFERS 
takes care of the 
*/ 
/* initialization 
required 
for 
general 
*/ 
/* SUPERVISOR 
TASK start 
up. 
*/ 
/*****************************************/ 


return 
th in mbx 
= rqScreateSmailbox 


(queue 
fifo, @status); 


call 
rqScatalogSobJect 
(supervisor 
job, return 
th in mbx, 


@(9,'SUP 
TH IN'), @statusl; 


return 
th,out mbx = rqScreateSmailbox 
- 
(queue fifo, @status); 


call 
rqScatalogSobJect 
(supervisor 
job, return th out mbx, 
@(lO,'SUP 
TH OUT'), 
@statUS); 
to_input_mbx 
= rqScreateSmailbox 
(queue fifo, 0status); 
call 
rqScatalogSobject 
(supervisor 
job, to input mbx, 
@(12,'TO 
INPUT MBXT), 0status); 
to fft mbx 
= rqScreateSmailbox 
(queue_priority, 
@status); 


inter 


536 
537 


538 
539 


542 
543 


544 
545 


546 
547 


call 
rq$catalogSobject 
(supervisor 
job, to fft mbx, 


~(lO,'TO 
FFT MBX')~ 
@status); 


to_output_mbx 
= rq$create$m?ilbox 
(queue priority, 
tastatus); 
call 
rq$catalog$object 
(supervisor 
job, to output 
mbx, 


@(lO,'TO 
OUT MBX')~ 
@status); 


to supervisor 
mbx 
= rq$createSmailbox 
- 
(queue 
priority, 
@status); 


call 
rq$catalogSobject 
(supervisor 
job, to supervisor 
mbx, 


@(lO,'TO 
SUP MBX')~ 
@status);- 


root_Job_token 
= rqSget$taskStokens 
(rootjob, @status); 
th out mbx 
= rqSlookup$object 
(root job token, @(ll,'RQTHNORMOUT'), 
wait-forever, 
@status); 
th in mex 
~ 
rq$lookup$object 
(root job token, l<l(lO,'RQTHNORMIN'), 
wait=forever, 
I<lstatus); 


th in segment 
token 
= 
rq$create$segment 
- 
(size 
120 bytes, 
@status); 


call 
rq$catalog$obJect~ 
(supervisor 
job, th in segment 
token, 


@(lO,'S 
THIN SEG')~ 
@status);- 


th in segment 
pointer 
values.offset 
= 0; 
th-in-segment-pointer-values.base 


- 
- 
- 
= th 
in segment 
token; 
th in segment.function 
- 
- 
= th read; 
th=in=segment.count 
-= 82; 


th_out_segment_token 
rq$create$segment 
(size 120 bytes, 
@status); 
call 
rq$catalog$obJect- 
(supervisor 
job, th out segment 
token, 


@(ll,'S 
THOUT SEG'), 
@status);- 
th out segment 
pointer 
values.offset 
= 0; 
th-out-segment-pointer-values.base 
- 
- 
- 
= th-out 
segment 
token; 


th out segment.function 
- 
th-write; 
th=out=segment.count 
- 
111; 


do general 
index = 0 to 2; 


th out segment.home 
chars 
(general 
index) 


- 
- cursor 
home-chars 
(general-index); 


/*************************************************/ 
/* At last, the SUPERVISOR 
TASK! 
~11 it does 
is */ 


inter 


/* 
call 
other 
procedures 
to 
initialize 
the 
*/ 


/* screen, 
input 
the 
parameters, 
clean 
up 
the 
*/ 


/* old 
FFT 
segments 
from 
the 
mailboxes, 
set 
up 
*/ 


/* new 
segments, 
create 
the 
tasks, 
and 
then 
wait 
*/ 


/* 
for 
messages 
from 
the 
operator 
(abort) 
or 
*/ 


/* other 
tasks 
(FFT 
or 
OUTPUT 
done) • 
*/ 


/*************************************************/ 


553 
554 


call 
initial 
screen; 
call 
initiaITze_tasks; 


556 
557 
558 


call 
input 
parameters; 
call 
initialize 
segments; 
call 
monitor_maTlboxes; 


END 
SUPERVISOR_TASK; 


END 
SUPERVISOR_MODULE; 


CODE 
AREA 
SIZE 
CONSTANT 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
1197 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


1032H 
OOOOH 
0084H 
0024H 


414fiD 
OD 
132D 
31)D 


ISIS-II 
PL/M-86 
V2.0 
COMPILATION 
OF 
MODULE 
INPUT 
TASK 
MODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:input.OBJ 


COMPILER 
INVOKED 
BY: 
plm8n 
:Fl:input.p86 
$title('INPUT 
TASK 
FOR 
AP 
NOTE 
110, 
OCTOBER 
1980') 


$large 
debug 
INPUT 
TASK 
MODULE: 
do; 
, . 


$include(:fl:nucprm.ext) 
$SAVE 
NOLIST 


99 
100 
101 
102 
103 
104 
105 
106 
107 
108 
109 
110 
111 
112 
113 
114 
115 
lln 
117 
118 
119 
120 
121 
122 
123 


/* The 
following 
two 
tokens, 
the 
FF! 
sample 
*/ 


/* 
segment 
format, 
and 
the 
root 
job 
directory 
*/ 


/* 
form 
the 
entire 
interface 
for 
this 
task 
with 
*/ 


/* 
the 
rest 
of 
the 
system. 
*/ 


declare 
to 
input 
mbx 
declare 
to-fft 
mbx 
token 
external; 


token 
external; 


declare 
declare 
declare 
declare 
declare 
declare 
declare 


declarel 
dec;,lare 
declare 
decl,are 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
decla.re 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 


ascii 
mask 
carriage 
return 
done 
- 
first 
loop 
forever 
frames 
to 
process 
entry 
hardware 
Tnterrupt 
level 
3 
literally'0038H'; 


interrupt 
task 
created 
literally 
'OFFH'; 


interrupt-task-not 
created 
literally 
'OOH'; 


latch 
the-data 
- 
literally'040H'; 


line 
feed 
literally'OAH'; 


-new fft 
run 
literally 
'OFFH'; 


no 
response 
requested 
literally 
'OOH'; 


no-data 
segment 
literally 
'DOH'; 


not 
done 
literally'OOH'; 


not-first 
loop 
literally 
'OOH'; 


not-valid 
literally 
'DOH'; 


null 
literally'OOH'; 


processed 
so 
far 
entry 
literally 
'33'; 


queue 
fifo 
- 
literally 
'OOH'; 


root job 
literally'03H'; 


run 
continuous 
literally 
'OFFFFH'; 


sample 
LSB 
literally 
'008lH'; 


sample-MSB 
literally 
'OOaOH'; 


size 
2-bytes 
literally 
'2'; 


size-120 
bytes 
literally 
'120'; 


supervisor 
job 
literally 
'OOH'; 


th 
write, 
literally 
'OS'; 


thTs 
is 
the 
interrupt 
task 
literally 
'OlH'; 


timer 
one 
port 
- 
literally 
'OOD2H'; 


timer-mode 
control 
port 
literally'OODnH'i 


valid- 
- 
- 
literally 
'OFFH'; 


literally'30H'; 
literally'ODH'; 
literally'OFFH'; 
literally'OFFH'; 


literally 
'while 
1'; 


literally 
'50'; 


inter 


125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
1311 
137 
138 
139 


144 
145 
146 
147 
148 
149 


declare 
data 
segment 
token 


declare 
dummy 
mbx 
- 


declare 
from 
Interrupt 
task 
mbx 


declare 
handler 
dummy 
mbx 
- 


declare 
handler-status 


declare 
interrupt 
status 


declare 
interrupt-task 
token 


declare 
interrupt-message 
token 


declare 
output 
buffer 
token 


declare 
return-mbx 
- 


declare 
root 
job 
token 


declare 
signal 
interrupt 
token 


declare 
status- 
- 


declare 
to 
interrupt 
task 
mbx 


declare 
th-out 
mbx 
- 
- 


token; 
token; 
-token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 
token; 


declare 
sample 
input 
data 
structure( 
LSB 
- 
byte, 
MSB 
byte) 
at 
(~sample_data); 


word; 


I 


declare 
timer 
values 
structure( 
LSB 
- 
byte, 
MSB 
byte) 
at 
(@current_timer_value); 


declare 
done 
flag 


declare 
firs£ 
input 
loop 
flag 


declare 
frames 
receIved 


declare 
general 
index 


declare 
interrupt 
task 
flag 


declare 
sample_valid 
- 


declare 
timer 
threshold 


byte; 
byte; 
byte; 
byte; 
byte; 
byte; 


declare 
converted 
value 
structure( 
first 
digIt 
byte, 
second_digit 
byte) ; 


/* 
The 
following 
declare 
is 
for 
the 
home 
*/ 
/* 
characters 
for 
the 
Hazeltine 
terminals. 
*/ 
/* 
The 
sequence 
is 
tilde, 
DC2. 
*/ 


lIi2 
Hi3 


declare 
output 
buffer 
pointer 
values 
structure( 


offset 
- 
word~ 
base 
word) 
at 
(@output_buffer_pointer) ; 


declare 
output 
buffer 
based output 
buffer_pointer 


structure( 
function 
word, 
count 
word, 
exception 
code word, 
actual 
- 
word, 
home 
chars(2) 
byte, 
line-index(24) 
byte, 
character(80) 
byte); 


declare 
data_segment_pointer 
pointer 
public; 


declare 
data segment 
pointer 
values 
structure( 


offset 
- 
word, 
base 
word) at 
(@data_segment_pointer) ; 


/* The 
following 
is the FFT data 
segment 
format. */ 


declare 
data 
segment 
based data segment 
pointer 


structure( 
-- 
samples 
per frame 
word, 
sample interval 
word, 
frames-to 
average 
word, 
continuous 
flag 
word, 
this 
frame-number 
word, 
number 
samples 
missed 
word, 
sample-pointer- 
word, 
reset flag 
word, 
sample(256) 
integer) ; 


declare 
input status 
line(80) 
byte data 
(' - 
The INPUT 
TASK has processed' 


, 
frames out of 
frames 
to' 
, average. 
'); 


FAST 
INPUT HANDLER: 
PROCEDURE 
(FFT SEGMENT 
POINTER) 
EXTERNAL; 
DECLARE 
FFT SEGMENT 
POINTER 
POINTER; 
END FAST_INPUT_HANDLER; 


/************************************************/ 
/* SLOW 
INPUT HANDLER 
is an interrupt 
procedure 
*/ 
/* that-receives 
an interrupt 
when 
the 8253 
*/ 


/* 
interval 
timer counts 
to zero. 
The 8253 is 
*/ 
/* free 
running, 
so it starts 
counting 
from the */ 
/* top again. 
The 8253 counter 
is tested 
*/ 
/* 
in a polling 
fashion 
to be sure 
it reads the */ 
/* sample, 
which 
resets 
the conversion, 
*/ 
/* at a precise 
time. 
This aids 
in removing 
*/ 


165 
Hi6 


167 
168 


169 
170 
171 
172 
173 


174 
175 
176 


177 
178 


179 
180 


/* 
jitter 
from 
the 
sample 
intervals. 
When 
all 
*/ 
/* 
of 
the 
samples 
have 
been 
taken, 
*/ 


/* 
SLOW 
INPUT 
HANDLER 
calls 
signal 
interrupt, 
*/ 


/* 
which 
lets-the 
INTERRUPT_TASK 
procedure 
know 
*/ 
/* 
the 
buffer 
is 
full. 
*/ 


/************************************************/ 


SLOW_INPUT_HANDLER: 
PROCEDURE 
INTERRUPT 
59 
PUBLIC; 


/* 
First 
set 
the 
sample 
to 
not 
valid 
(we 
have 
*/ 
/* 
to 
be 
past"the 
timer 
threshold 
before 
the 
*/ 
/* sample 
becomes 
valid). 
*/ 


sample 
valid 


timer_loop: 


output 
(timer 
mode 
control 
port) 
= 
latch 
the 
data; 


timer 
values.LSB 
-input 
(Timer 
one 
port)~ 
- 


timer=values.MSB 
= 
input 
(timer=one=port); 


/* 
If 
it 
is 
not 
past 
the 
threshold, 
then 
some 
*/ 
/* 
future 
sample 
will 
be 
valid. 
*/ 


if 
current 
timer 
value 
> 
timer 
threshold 
then 
do; 
sample 
valid 
= valid; 
goto 
tTmer 
loop; 
end; 


/* We 
get 
to 
the 
else 
only 
if 
we 
are 
past 
the 
*/ 
/* timer 
threshold. 
*/ 


else 
do; 
sample 
input 
data.LSB 
= 
input(sample 
LSB); 


sample=input=data.MSB 
= 
input(sample=MSB); 


If 
the 
sample 
is 
valia, 
in 
before 
the 
threshold 
sampled 
as 
close 
to 
the 
possible. 


we 
must 
have 
come 
*/ 


so 
we 
know 
we 
*/ 


right 
time 
as 
*/ 
*/ 


if 
sample 
valid 
do; 
- 


/* However, 
we 
want 
to 
ignore 
the 
first 
*/ 


/* sample 
(which 
was 
started 
a 
long 
*/ 


/* 
time 
ago). 
*/ 


if 
first 
input 
loop 
flag 
= 
first 
loop 
then 


first 
Tnput 
loop 
flag 
not 
first 
loop; 


else 
- 
- 
- 
-- 
do; 


data 
segment.sample 
(data 
segment.sample 
pointer) 


= sample 
data; 
- 
data 
segment.sample 
pointer 
data_segment:sample_pointer+l; 


end; 
else 
do· 
data 
segment.number 
samples 
missed 
~ 
data 
segment.number 
samples 
missed+l; 


data 
segment.sample 
pointer 
= 
0; - 
end; 
- 
- 
sample 
valid 
not_valid; 
end; 
- 


If 
we 
are 
done, 
we 
have 
to 
let 
the 
*/ 


INPUT 
TASK 
know 
the 
buffer 
is 
full. 
*/ 


Otherwise, 
we 
wait 
for 
the 
next 
interrupt. 
*/ 


if 
data 
segment.sample 
pointer 
>= 
data 
segment:samples 
per 
frame 
then 


call 
rqSslgnalSinterrupt 
- 
(hardware 
interrupt 
level 
3, 
@handler-status); 
- 
else 
call 
rqSexitSinterrupt 
(hardware 
interrupt 
level 
3, 
@handler=status) 
; 


END 
SLOW 
INPUT_HANDLER; 


/*************************************************/ 
/* INTERRUPT 
TASK 
exists 
because 
if 
an 
interrupt 
*/ 
/* task 
goes-to 
sleep, 
the 
level 
of 
the 
*/ 
/* 
interrupt 
task, 
interrupt 
handler, 
~nd 
lower 
*/ 
/* levels 
remain 
disabled. 
In 
order 
to 
prevent 
*/ 


/* 
this 
from 
happening 
in 
this 
application, 
this 
*/ 


/* task 
notifies 
the 
INPUT 
TASK 
that 
the 
buffer 
*/ 
/* is 
full. 
INPUT 
TASK 
disables 
Level 
3 and 
*/ 


/* 
returns 
the 
token 
to 
INTERRUPT 
TASK. 
*/ 


/* INTERRUPT 
TASK 
will 
then 
call 
wait 
interrupt, 
*/ 
/* enabling 
lower 
levels. 
Since 
INPUT 
TASK 
*/ 
/* 
disabled 
Level 
3, 
no 
Level 
3 
interrupts 
will 
*/ 
/* be 
serviced 
until 
Level 
3 
is 
enabled 
by 
*/ 
/* 
INPUT 
TASK. 
*/ 
/* 
*/ 
/* NOTE 
THAT 
PLM/8h 
REQUIRES 
THE 
USE 
OF 
THE 
*/ 
/* BUILT 
IN 
INTERRUPTSPTR 
PROCEDURE 
TO 
OBTAIN 
*/ 


/* THE 
PROPER 
INTERRUPT 
~ROCEDURE 
ENTRY 
POINT. 
*/ 
/* 
*/ 


/*************************************************/ 


inter 


198 


199 


205 
206 


207 
208 
209 


210 
211 


call 
rqSset$interrupt 
(hardware 
interrupt 
level 
3, 
this 
is the 
interrupt 
task, 
INTERRUPTSPTR(SLOW 
INPUT 
HANDLER), 


no_data_segment, 
~Tnterrupt_status); 


call 
rq$waitSinterrupt 
(hardware 
interrupt 
level 
3, 
@interrupt_status); 


call 
rqSsendSmessage 
(from 
interrupt 
task 
mbx, 
interrupt 
message 
token, 
to_interrupt 
task=mbx, 
@interrupt_status); 


interrupt 
message 
token 
= 
rqSreceiveSmessage 


(to 
interrupt 
task 
mbx, 
wait 
forever, 
@dummy_mbx, 
@interrupt_statuS); 


/************************************************/ 
/* 
CONVERT 
DIGITS 
is 
a 
small 
procedure 
for 
*/ 


/* converting 
a hex 
number 
into 
an 
ASCII 
*/ 


/* number, 
with 
the 
advance 
knowledge 
that 
the 
*/ 
/* hex 
number 
will 
be 
less 
than 
99 
decimal 
(in 
*/ 
/* 
this 
case, 
less 
than 
32 
decimal) 
• 
*/ 


/************************************************/ 


converted 
value.first 
digit 
converted=value.second_digit 
=.ascii 
mask; 
asci i=mask; 


done 
flag 
do 
while 
done 
flag 
not 
done; 
not=donej 


/* The 
problem 
here 
is 
we 
need 
to 
check 
for 
*/ 
/* 
a 
negative 
value 
when 
we 
have 
BYTE 
values 
*/ 
/* 
which 
are, 
by 
definition, 
positive 
and 
*/ 
/* 
mudulo 
256. 
So 
we 
adapt 
by 
checking 
for 
*/ 
/* > 
200 
decimal, 
which 
should 
mean 
the 
*/ 
/* value 
has 
"wrapped" 
around 
zero. 
If 
it 
*/ 


/* 
has, 
we 
can 
get 
our 
previous 
value 
back 
*/ 


/* 
by 
adding 
10. 
*/ 


if 
value 
to 
convert 
< 
200 
then 
converted=value.first_digit 


inter 


212 
213 
214 


215 
216 
217 


else 
do; 
value 
to 
convert 
= 
value 
to 
convert 
+ 
10; 


converted 
value.second 
dIgit 
= converted 
value.second 
digit 
+ 


value 
to 
convert; 
- 
done 
flag 
= done;- 
- 
end; 
end; 


/**********************************************/ 
/* SEND 
STATUS 
converts 
the 
current 
frame 
*/ 
/* number 
into 
ASCII 
and 
stuffs 
it 
into 
the 
*/ 
/* previously 
initialized 
status 
line. 
Then 
*/ 


/* SEND 
STATUS 
sends 
the 
status 
line 
to 
the 
*/ 


/* 
termInal 
handler 
and 
waits 
for 
the 
segment 
*/ 
/* to 
be 
returned. 
*/ 


/**********************************************/ 


output 
buffer.character 
(processed 
so 
far 
entry) 


- 
= 
converted 
value.fIrst-digit; 


output 
buffer.character 
(processed 
so 
far-entry+l) 


- 
converted_value.second_digit; 


output 
buffer.character 
(frames 
to 
process 
entry) 


- 
= 
converted 
value. first 
digit; 


output 
buffer.character 
(frames 
to 
process 
entry+l) 


- 
= converted_value.second=digit; 


call 
rqSsendSmessage 
(th 
out 
mbx, 
output 
buffer 
token, 


return-mbx, 
@status); 
output_buffer 
token 
- 
rqSreceiveSmessage 
(return 
mbx, 
wait 
forever, 


@dummy=mbx, 
~status); 


/***********************************************/ 
/* 
INPUT 
DATA 
selects 
the 
fast 
or 
slow 
input 
*/ 
/* handler, 
initializes 
the 
8253 
timer 
as 
*/ 


/* necessary, 
and 
calls 
the 
appropriate 
input 
*/ 


inter 


/* handler. 
Please 
note 
the 
values 
of 
the 
*/ 
/* 
intervals 
selected 
for 
sampling 
are 
*/ 
/* 
scaled 
by 
~n/~4 
so 
the 
actual 
frequency 
*/ 
/* 
output 
of 
the 
128 
sample 
FFT 
algorithm 
will 
*/ 
/* match 
up 
with 
the 
base 
10 
x 
axis 
labels. 
*/ 
/* Base 
10 doesn't 
map 
too 
well 
to 
a binary 
*/ 
/* 
x-axis 
that 
runs 
from 
1 to 
~4. 
*/ 
/***********************************************/ 


231 
1 
INPUT 
DATA: 
PROCEDURE; 
- 


232 
2 
declare 
LSB 
120Hz 
interval 
li terally 
'0 58H' ; 
233 
2 
declare 
MSB-120Hz - interval 
literally 
'002H' ; 


234 
2 
declare 
LSB-~(lOHz-interval 
1iterally 
'078H'; 
235 
2 
declare 
MSB""""":600Hz 
- interval 
literally 
'OOOH'; 


< 


236 
237 


239 
240 
241 
242 
243 
244 
245 
246 
247 


/* 
The 
8253 
timer 
is 
runnin~ 
at 
143.6 
Khz, 
or 
*/ 
/* 
~.5 
microseconds 
per 
count. 
We 
have 
to 
*/ 


/* 
restart 
the 
sampling 
process 
precisely, 
so 
*/ 
/* we 
count 
down 
after 
the 
interrupt 
to 
be 
*/ 
/* 
sure 
we 
are 
synchronized. 
In 
this 
case, 
*/ 
/* 
we 
have 
a 
300 
microsecond 
window 
after 
the 
*/ 
/* 
interrupt 
to 
get 
the 
sample. 
300 
*/ 
/* microseconds 
is 
roughly 
~2 
times 
h.5 
*/ 


/* microseconds. 
*/ 


declare 
threshold 
for 
120Hz 


declare 
threshold 
for-~OOHz 
literally'022EH'; 
literally'0048H'; 


declare 
a 
3906 
microsecond 
interval 
literally'OF42H'; 
dec;are 
five 
places 
literally'S'; 


declare 
nucleus 
allocated 
stack 
literally 
'OOH'; 
declare 
shift_integer_right 
literally 
'SAL'; 
declare 
software 
priority 
level 
0 
literally 
'OOg'; 


declare 
software-priority-level 
66 
literally 
'~6'; 


declare 
stack 
size 
512 
- 
literally 
'512'; 


declare 
task 
Ylags- 
literally 
'oOH'; 


declare 
this-task 
literally 
'OOH'; 


declare 
timer 
mode 
control 
word 
literally 
'74H'; 


/* The 
first 
thing 
we 
do 
is 
start 
~he 
~onver- 
*/ 
/* 
sions. 
We 
don't 
care 
about 
the 
first 
*/ 
/* data 
since 
we 
are 
going 
to 
ignore 
it. 
Each 
*/ 
/* time 
we 
read 
both 
bytes 
of 
the 
present 
*/ 
/* converted 
value, 
we 
start 
the 
next 
*/ 
/* conversion. 
This 
initialization 
will 
*/ 


/* prepare 
for 
the 
real 
data 
gathering. 
*/ 


inter 
APPENDIX 
B 


251 
2 
252 
2 
253 
3 


254 
3 


255 
3 
256 
4 


257 
<1 


258 
4 


259 
4 


260 
3 
21i1 
4 


262 
4 


203 
4 


21i4 
4 
2&;5 
3 


21i6 
3 


21i7 
3 
2,,8 
4, 


271 
272 


if 
data 
segmenLsamp1e 
intervalJ) 
391 
then 
do; 
~ 
output 
(timer 
mode 
control 
port) 


* 
= 
timei 
mod~ 
controT 
word; 


if 
da,ta segment 
.,sample 
interval 
-;-a .3906- micros~cond 
i,n,terval then 


do; 
timer 
threshold 


'. 
. = threshold 
for '120Hz; 
out'put 
(t:imer :One'port) 
= 
LSB 
120Hz 
il1-terval; 
output 
(timer 
one 
port) 
MSB_120Hz_interval; 
'"'I' 


end; 
else 
do; 
timer 
,threshold 
= thJ;:es,holdfo.r l.iOOHz; 
outp.ut 
(timer 
one 
por,t), 
O' 


~'LSBIiOOHz 
int~rval; 
output 
(timer 
one 
port) 
j." 
=MSB 
~OOHz 
intervat; 
end; 
- 
first_input 
loop_flag 
= 
fir~t_loop; 


interrupt 
task 
flag 
int~~rupt~task~created; 


end; 
else 
call 
rqSenable 
(hardware 
interrupt~level~3, 
@status); 


/* 
Now 
we 
wait 
until 
the-slow 
handler 
*/ 


/* 
fills 
the 
buffer; 
;.. 
10 
*/ 
.~ 
. 
- 
( , 


signal 
'interrupt 
token 
.= .,rqSreceiveSmessage 


-(from 
int~rrupt 
task 
mbx, 
wait 
forever, 


" 
@dummy_mbx,.@status); 
- 


/*.-If we. get 
t·he·.token, 'wer-know the 
buffer 
*/ 
,. 


/* 
is 
full, 
so·we,disClb:j.E!'levelo3 
*/" 


intJ 


279 
280 


282 
283 


285 
286 
287 


290 
291 


call 
rq$disable 
(hardware_interrupt_Ievel_3, 
@status); 


/* And 
return 
the 
token 
so 
the 
*/ 
/* 
INTERRUPT 
TASK 
can 
enable 
lower 
*/ 
/* interrupt 
levels. 
*/ 


call 
rqSsendSmessage 
(to 
interrupt 
task 
mbx, 
signal 
interrupt 
token, 
no_response_requested, 
~status); 


end; 
else 
do; 


/* The 
fast 
INPUT 
handler 
must 
sample 
at 


/* precise 
intervals 
that 
no 
not 
allow 
/* variable 
interrupt 
latency. 
Therefore 


/* we 
raise 
the 
priority 
level 
to 
O--the 
/* highest--and 
just 
sample 
in 
a 
polling 


/* fashion 
until 
the 
buffer 
is 
filled. 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


call 
rqSset$priority 
(this 
task, 
software 
priority 
level 
0, 


@status) 
; 
- 
call 
FAST 
INPUT 
HANDLER 
(data 
segment 
pointer); 


call 
rq$setSpriority 
- 
- 


'(this 
task, 
software 
priority 
level 
fifi, 


@status) 
; 
- 
- 


do 
general 
index 
= 
0 to 
127; 
data 
segment.sample 
(general 
index) 
shift 
integer 
right 
- 
(data_segment.sample 
(general 
index), 


five_places) 
; 


do 
general 
index 
= 
128 
to 
255; 
data 
segment.sample 
(general 
index) 
end; 
- 


/**********************************************/ 
/* UPDATE 
FRAME 
NUMBER 
just 
updates 
the 
frame 
*/ 
/* number-parameter 
on 
the 
data 
segments. 
*/ 


/**********************************************/ 


data 
segment.number 
samples 
missed 


data=segment.sample=pointer- 


inter 


294 
295 
296 
297 
298 


299 
300 


if 
frames 
received 
= 
data 
segment.frames 
to 
average 
then 
frames_received 
=-0; 
- 


if 
data 
segment.reset 
flag 
do; 
- 
- 
frames 
received 
= 
0; 
data 
segment.reset 
flag 
end; 
- 
- 


frames 
received 
frames 
received 
+ 
1; 


data_segment.this_frame 
number 
frames 
received; 


/***********************************************/ 
/* 
INITIALIZE 
BUFFERS 
takes 
care 
of 
the 
usual 
*/ 
/* trivia 
of 
setting 
up 
the 
pointers, 
creating 
*/ 
/* 
the 
return 
mailbox, 
looking 
up 
the 
terminal 
*/ 
/* 
handler, 
and 
all 
that 
other 
small 
garbage. 
*/ 
/***********************************************/ 


return 
mbx 
= 
rq$create$mailbox 


(queue 
fifo, 
I'lstatus); 


call 
rqScatalogSobject 
(supervisor 
job, 
return 
mbx, 
@(9,'I 
RET-MBX'), 
(,\status); 


from 
interrupt 
task 
mbx 
= 
rq~createSmailbox 


(queue 
firo, 
@status); 


call 
rq$catalog$object 
(supervisor 
job, 
from 
interrupt 
task 
mbx, 
@(12,'FM 
INTSK 
MBX')~ 
~status); 


to 
interrupt 
task 
mbx 
rq$create~mailbox 


(queue 
fifo, 
@status); 


call 
rq$catalog$object 
(supervisor 
job, 
to 
interrupt 
task 
mbx, 
(.l(12,'TO INTSK 
MBXT), @status); 


interrupt_message 
token 
= 
rqScreateSsegment 


. (size 
2-bytes, 
@status); 


call 
rqScatalog$object 
(supervisor 
job, 
interrupt 
message 
token, 


t<!(10,'INTTSK MSG'), 
@status); 


interrupt 
task 
flag 


-= 
interrupt_task_not_created; 


output_buffer 
token 
= 
rqScreateSsegment 
(si~e 
120 
bytes, 
~status); 


call 
rq$catalog$object 
(supervisor 
job, 
output 
buffer 
token, 


@(10,'I 
BUFF 
SEG'), 
@status);- 


314 
2 
315 
2 


31'5 
2 
317 
2 
318 
2 
319 
3 


320 
3 


321 
2 
322 
3 


323 
3 


324 
2 
325 
3 


326 
3 


327 
2 


328 
3 


329 
3 


330 
2 


331 
2 


output 
buffer 
pointer 
values.offset 
0; 


output-buffer-pointer-values.base 
- 
= output 
buffer 
token; 
output 
buffer.functTon 
= tn write; 
output-buffer.count 
= 110; 
do general 
index = 0 to '5; 
output 
buffer.home 
chars 
(general 
index) 


- 
cursor nome 
chars 
(general 
index); 


do general 
index = 0 to 21; 
output 
buffer.line 
index 
(general index) 


- 
line_feed; 


do general 
index = 
22 to 23; 
output 
buffer.line 
index 
(general index) 


- 
= null; 
- 


do general 
index = 0 to 78; 
output 
buffer.character 
(general index) 


- 
input_status_line 
(ge~eral index); 


root job token = rqSgetStaskStokens 
(rootjob, @status); 
th out mbx 
= rqSlookup$object 
(root job token, ~(II,'RQTHNORMOUT'), 
wait=forever, 
@status); 


frames 
received = 0; 


/**********************************************/ 
/* The actual 
INPUT TASK begins 
here. 
It 
*/ 


/* 
initializes 
the buffers 
to begin 
things, 
*/ 
/* then waits 
forever 
for the FFT sample 
*/ 


/* segment. 
It then samples 
the data, 
fills 
*/ 


/* the FFT data 
segment, 
and sends 
it to the 
*/ 


/* 
FFT TASK. 
The 
INPUT TASK 
then updates 
its */ 
/* status 
line, sends 
it to the terminal 
*/ 


/* handler, 
and returns 
to the mailbox 
to 
*/ 
/* wait 
forever. 
*/ 
/**********************************************/ 


334 
I 
INPUT TASK: 
PROCEDURE 
PUBLIC; 


335 
2 
call 
initialize 
buffers; 
- 


336 
2 
data 
segment 
pointer 
values.offset 
0; 
- 
- 
- 


337 
2 
do forever; 


inter 


/* Wait 
forever 
for 
an 
FFT data 
segment 
~t 
*/ 
/* 
the 
to_input_mbx. 
*/ 


data_segment 
token 
= 
rqSreceiveSmessage 


(to 
input 
mbx, 
wait 
forever, 
@dummy 
mbx, 
~status); 
data 
segment 
pointer 
values.base 
- 
~ 
data_segMent_token; 


call 
update 
frame 
number; 
call 
input_data; 
- 


340 
341 


call 
send_status; 


call 
rqSsendSmessage 
(to_fft_mbx, 
data 
segment 
token, 


no_response_requested, 
@status); 


END INPUT_TASK; 


END INPUT_TASK_MODULE; 


CODE 
AREA SIZE 


CONSTANT 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK SIZE 


754 LINES READ 
o PROGRAM 
ERROR(S) 


OF PL/M-8n COMPILATION 


1803D 
OD 
54D 
42D 


070BH 
OOOOH 
0036H 
002AH 


inter 


MCS-86 
MACRO 
ASSEMBLER 
FSTINP 
ISIS-II 
MCS~86 
MACRO 
ASSEMBLER 
V2.1 
ASSEMBLY 
OF 
MODULE 
FSTINP 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:FSTINP.OBJ 
ASSEMBLER 
INVOKED 
BY: 
asm86 
:fl:fstinp.aR6 


LOC 
OBJ 
LINE 


1 
2 
3 


4 
5 


6 


7 


8 


9 


10 


11 
12 


13 


14 


15 


1'5 


17 


18 


19 


20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 


FAST 
INPUT 
HANDLER 
for 
APNOTE 
110, 
OCTOBER 
1980 


FAST 
INPUT 
HANDLER 
is 
an 
assembler 
routine 
that-runs 
at 
priority 
level 
0 and 
simply 
drives 
an 
analog 
to 
digital 
convertor 
and 
stuffs 
the 
samples 
into 
a data 
segment 
until 
all 
of 
the 
samples 
have 
been 
taken. 
FAST 
INPUT 
HANDLER 
has 
passed 
to 
it 
the 
address 
of 
the 
data 
segment, 
in 
which 
the 
offset 
is 
known 
to 
be 
zero. 
FAST 
INPUT 
HANDLER 
returns 
nothing 
to 
the 
callIng 
routine. 


FAST 
INPUT 
HANDLER 
provides 
the 
proper 
timing 
for 
sampling 
at 
a 
39, 
78, 
and 
391 
microsecond 
intervals 
using 
timed 
loops 
of 
software 
instructions. 
In 
order 
to 
provide 
an 
FFT 
without 
large 
amounts 
of 
jitter, 
the 
sample 
intervals 
must 
be 
uniform 
in 
time. 
iRMX 
86 
cannot 
guarantee 
this 
uniformity 
due 
to 
its 
real 
time 
design, 
so 
this 
routine 
takes 
complete 
control 
of 
the 
processor 
for 
the 
(39 
times 
128) 
4.9 
milliseconds 
or 
(78 
times 
128) 
9.9 
or 
(391 
times 
128) 
50 
milliseconds 
required 
to 
complete 
a 
frame 
of 
128 
samples. 


AX 
- general 
CX 
- 
loop 
delay 
counter 
BX 
- 
stack 
index 
DX 
- 
sample 
value 


BP 
- stack 
SP 
- stack 
DI 
- 
offset 
index 
into 
FFT 
SI 
- 
not 
used 
data 
segment 


DS 
- 
base 
for 
FFT 
data 
segment 


inter 


0080 
0081 
00 DE 
0002 
0002 
alOE 


0000 
(20 
0000 
) 


50 
???? 
51 
52 
53 
54 
55 
56 
57 
58 


1;4 
0000 
65 
~n 
0000 
IE 
67 
0001 
55 
fi8 


; 
.********************************************** 
, 


; 
ASSUME 
DS:FAST 
INPUT 
DATA, 
SS:STACK, 
CS:FAST=INPUT=CODE, 
ES:NOTHING 
; 
PUBLIC 
FAST 
INPUT 
HANDLER 
; 
SAMPLE 
LSB 
SAMPLE-MSB 
FIRST 
PASS 
SAMPLE 
INCREMENT 
SAMPLE-INTERVAL 
SAMPLE-MAX 


; 
FAST 
INPUT 
DATA 


; 
STACK 
ENDS 


; 
FAST 
INPUT 
CODE 


; 
FAST 
INPUT 
HANDLER 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


0080H 
aORIH 
14 
2 
2 
270 


SEGMENT 
WORD 
PUBLIC 
'DATA' 


SEGMENT 
PARA 
PUBLIC 
'CODE' 


; 
PUSH 
DS 
PUSH 
BP 
; SAVE 
BP 
IN 
STACK 
MOV 
BP, 
SP 
; SET 
BP 
TO 
STACK 
POINTER 
MOV 
DS, 
rBP + 
10] 
; PUT 
BASE 
OF 
SAMPLE 
SEGMENT 
IN 
DS 
MOV 
DI, 
SAMPLE 
INTERVAL 
; DX 
IS 
USED 
TO 
INDEX 
I~TO 
THE 
DATA 
SEGMENT 


MOV 
AX, 
DS: fOI] 
; SET 
AX 
TO 
SAMPLE 
INTERVAL 
PARAMETER 
MOV 
DI, 
FIRST 
PASS 
; RESET 
DI 
TO-FIRST 
SAMPLE 
- 
14 
CMP 
AX, 
39 
IF 
AX = 
39, 
SET 
LOOP 
VALUE 
TO 
9--LOOP 
JZ 
SET 
39 
US 


inter 


; TAKES ABOUT 
1 US PER DECREMENT 
CMP 
AX, 7fl 


; IF AX 
= 78, SET LOOP VALUE 
TO 
22--BASIC 


JZ 
SET 78 US 


CYCLE-IS-13 
US, PLUS 
(22 X 3) = 79 
US 


R 78 
MOV 
LOOP VALUE, 
12n 
; 391 IS-ONLY ONE LEFT-13 + 
(120X3) 


= 
391 
79 
JMP 
INPUT LOOP 
; 
R 80 
SET 39 US: 
MOV 
LOOP_VALUE, 
9 


;-TIMING 
IS BY SOF~NARE--SET 


DELAY COUNT 
JMP 
INPUT LOOP 
; 
SET 78 US: 
MOV 
LOOP_VALUE, 
7.2; 


INPUT-LOOP: 
MOV 
CX, 
LOOP VALUE 
; USE CX TO KEEP TRACK 
OF-DELAY 
84 
IN 
AL, SAMPLE 
LSB 


; SET AL TO LSB OF INPUT SAMPLE 


85 
MOV 
DL, AL 


; PUT THE LSB IN DL 
(8 BIT XFERS ONLY) 
86 
IN 
AL, SAMPLE MSB 
; SET AL TO MSB OF INPUT SAMPLE 


87 
; THIS RESTARTS 
SAMPLE 
PROCESS 


88 
MOV 
DH, AL 
; PUT AL 
IN DH TO COMPLETE 
THE VALUE 


003D 
83FFOE 
89 
CMP 
DI, FIRST PASS 
; WE WANT 
TO SKIP 
THE FIRST SAMPLE 


0040 7408 
90 
JZ 
SKIP 
INPUT 


0042 83C702 
91 
ADD 
DI, SAMPLE 
INCREMENT 


; INCREMENT 
DI-BY 
2 
92 
MOV 
DS: fDI], DX 
; PUT SAMPLE 
DATA 
IN SEGMENT 


0047 EB0990 
93 
JMP 
DELAY 


; AND JUMP TO SOFTWARE 
DELAY 
LOOP 


004A 83C702 
94 SKIP 
INPUT: 
ADD 
DI, SAMPLE 
INCREMENT 


; INCREMENT 
DI BY 2 
- 


95 
NOP 
; AND NOP FIVE TIMES 
FOR EVEN TIMING 


9':;NOP 
97 
NOP 


98 
NOP 


99 
NOP 
100 DELAY: 
NOP 


; THIS NOP ADDS 
3 CLOCKS 
PER DECREMENT 


0053 EOFD 
101 
LOOPNZ 
DELAY 


; DEC CX AND LOOP--1.5 
US PER DECREMENT 
0055 81FFOErr1 102 
CMP 
DI, SAMPLE MAX 
; COMPARE 
DI TO SEE IF WE ARE DONE 
0059 75Do 
103 
JNE 
INPUT LOOP 


; IF NOT,-GO 
BACK FOR ANOTHER 
SAMPLE 
104 
POP 
BP 
; OTHERWISE 
POP BP, DS, AND RETURN 
POP 
DS 
RET 
4H 


001F EB1090 
0022 C70600000900 


0028 EB0790 
002B C70600001600 
0031 
8BOEOOOO 


81 
R 
82 
R 
83 


004E 90 
004F 90 
0050 90 
0051 90 
0052 90 


005e 
IF 
105 
0050 CA0400 
IOn 
107 


inter 


108 
FAST 
INPUT HANDLER 
ENDP 
109 
; 


110 
FAST 
INPUT CODE 
ENDS 
111 
112 
END 


Both the RAM and ROM-based configurations 
will be 


discussed in this appendix. They are essentially identical 
processes. In either case, the first step is to define a map 
of system memory. Once the map is known, the follow- 
ing sequence is suggested for locating code in memory: 


1) Reserve memory OH to 03FFH for the Nucleus in- 


terrupt vector. 


2) If the system is RAM based and the code is loaded 


by the 
iSBC 
957A 
Monitor, 
reserve 
locations 
03FFH to 07FFH for the monitor's 
use. 


3) Configure 
each of the necessary portions 
of the 
iRMX 86 Operating 
System and locate them se- 


quentially in memory. 


4) For a RAM-based development system, allow 2K of 
RAM for the system Root Job. Placing the Root 
Job after the portions of the iRMX 86 Operating 
System, which are relatively fixed in size during 
development, and before the development code will 
give the Root Job a fixed address. This will prevent 
having to move the Root Job and reconfigure the 
system when the development code grows. For final 
EPROM-based 
systems, the Root Job should be 
placed after the development code. 


5) Link and locate each of the application code mod- 


ules sequentially in memory. 


6) Define the RAM available to the system. 


7) Define memory NOT available to the system. This 
includes 
application 
code, 
EPROM, 
and 
non- 


existent memory 
within the 
1 megabyte address 
space. 


8) Create the configuration file using the address maps 
produced by the locate steps and the memory map 
defined in steps 6 and 7. 


9) Create the Root Job from this configuration 
file. 


11) If the system has been fully debugged, load the code 
into EPROM and test the final system. 


The above steps are necessary for both the RAM devel- 
opment system and the final EPROM system. Convert- 
ing this application from RAM to EPROM requires re- 
configuring the Nucleus to include only those systems 
calls required by the application, 
substituting the Ter- 
minal Handler Job for the Debugger Job, removing any 
remaining system calls to catalog objects for debugging, 
and 
remapping 
the system to the EPROM 
address 
space. The memory maps for the development and final 
application are shown in Figures C-l and C-2. 


(RESERVED) 


RESET 
VECTOR 


iSBC 
957A 
MONITOR 
EPROM 
, 


SYSTEM 
RAM 


EXPANSiON 


APPLICATION 
DATA 


EXPANSION 


APPLICATiON 
CODE 


ROOT 
JOB 


DEBUGGER 


NUCLEUS 


iSBC 
957A 
MONITOR 


INTERRUPT 
VECTOR 


ADDRESS 


FFFFFH IEPROM 
FFFFOH 


FDOOOH 
},,, 


EXiSTENT 


20000H 


OFFFFH 


OED50H 


OEC10H 


OEB07H 


OCOBOH 
RAM 


OBACOH 


05330H 


OOOOH 


OOOH 


OH 


(RESERVED) 


RESET 
VECTOR 


UNUSED 
EPROM 


ROOT 
JOB 


APPLICATION 
CODE 


TERMiNAL 
HANDLER 
CODE 


NUCLEUS 
CODE 


SYSTEM 
RAM 


ROOT 
JOB 
DATA 


APPLICATION 
DATA 


TERMINAL 
HANDLER 
DATA 


NUCLEUS 
STACK 


NUCLEUS 
DATA 


INTERRUPT 
VECTOR 


ADDRESS 


FFFFFH 


FFFFOH 


FF5COH 
EPROM 


FD300H 


FCAOOH 


FBOOOH 


} 
NON- 
EXISTENT 


04000H 


OB90H 


OB80H 


OA58H 


RAM 


0990H 


OBOOH 


400H 


OH 


System configuration 
is a straightforward 
but exacting 


process. As with any such processes, there are some 
hints that can make development easier. In addition to 
care in locating the Root Job in memory, users should 
fix the initialization job entry point and the data RAM 
addresses. 


inter 


The Intel PL/M 
86 programming 
language does not 


allow a procedure to be used until after it has been de- 
clared. This requires the initialization procedure to be 
declared after all the other procedures. Since the initial- 
ization is last, changing the other procedures will change 
the location of the initialization procedure. If the system 
entry point changes, the system must be reconfigured. 
The moving entry point can be circumvented by writing 
a separate initialization task. The Root Job will create 
only the initialization task which will then initialize the 
system jobs. The initialization task entry point is fixed 
by linking it ahead of the other application tasks and by 
not changing the initialization task during dvelopment. 
The actual system entry points will be bound to the ini- 
tialization task during linking and locating. The linking 
and locating steps are a natural consequence of chang- 


ing the application code, so binding the fixed system en- 
try point is done automatically 
during development. 


The fixed initialization task entry point is used in the 
configuration 
file, giving the Root Job an unchanging 
system entry point. 


The remaining moving target during development is the 
RAM area for data and stack use. If the data and stack 
RAM is located before or after the application 
code, 


with enough extra memory in between for growth dur- 
ing development, the data and stack locations can stay 
constant. 
Fixing both the application 
entry point and 


the locations of the stack and data segments will allow 
development of the application code to proceed without 
requiring frequent reconfigurations. 
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SIngle-board 
microcomputers 
offer 
hardware 
cost-effectiveness 
for 


Implementing 
many rea/·time 
systems. A compatible, 
resident, 
rea/- 


tIme 
executive 
program 
provides 
savings 
in software 
development 


An Integral Real-Time Executive 
For Microcomputers 


Intel Corporation 
Santa 
Clara, 
California 


Single-board 
computers, or microcomputers, 
that contain 


central 
processor, 
read-write 
and 
programmable 
read- 


only memory, real-time clock, interrupts, 
and serial and 


parallel 
input/output 
all on one printed 
circuit 
board, 
have 
made 
feasible 
a whole 
spectrum 
of applications 


which 
previously 
could 
not 
be 
economically 
justified. 
These microcomputers 
have also opened up a range 
of 


applications 
where the high functional 
density of large- 
scale integration 
provides advantages 
over previous solu- 


tions 
such 
as hardwired 
logic 
or 
relatively 
expensive 


minicomputers. 
While microcomputers 
readily solve hard- 
ware 
requirements, 
software 
for 
single-board 
computer 


applications 
with 
real-time 
characteristics 
(which 
are 


in the majority) 
has until now been generated 
individu- 


ally for each application. 
The Intel RMX/80* 
Real-Time 
Multi-Tasking 
Execu- 


tive simplifies real-time application software development, 
and at the same time furnishes capabilities 
optimized for 
the microcomputer 
environment. 
It provides the means to 


concurrently 
monitor and control multiple external events 
that 
occur 
asynchronously 
in 
real-time. 
The 
program 


framework 
allows system builders to immediately 
imple- 


ment software 
for their 
particular 
applications, 
and to 


avoid specific details of system interaction. 
Major 
functions 
of the executive 
include 
system re- 


source access based on task priority, 
intertask communi- 


cation, 
interrupt 
driven 
device control, 
real·time 
clock 


control, 
and 
interrupt 
handling. 
In combination, 
these 
functions 
eliminate the need to implement detailed real· 
time coordination 
for specific applications. 


Previously, 
two alternative 
software 
approaches 
were 


used to solve microcomputer 
applications. 
First, 
many 


designers 
created 
their 
own operating 
executive, 
indi- 


vidually 
tailored 
for 
each 
application. 
Obviously, 
this 


approach was expensive and time-consuming. 
The second 


approach was to use a minicomputer 
executive which had 


been adapted 
to a microcomputer. 
Since this 
software 


was designed for a different processing environment 
and 


then 
"stripped 
down," 
it 
suffered 
from 
major 
inad- 


equacies when executed on microcomputers. 
The alterna- 


tive, RMX/80, 
has been designed specifically to provide 


a general-purpose 
real-time 
executive 
tailored 
to 
Intel 


SBC 80 and System 80 microcomputers. 


All software 
design approaches 
for use in real-time 
ap- 


plications 
include 
capability 
for 
concurrence, 
priority, 


and synchronization/communication. 


Concurrence-Real-time 
systems 
monitor 
and 
control 


events which are occurring 
asynchronously 
in the physi- 


cal world. Microcomputer 
software 
does not know ex- 


actly when external 
events will occur; 
however, it must 


be prepared 
to perform 
the necessary 
processing 
upon 


demand, whenever the events actually do occur. Typical- 
ly, interrupts 
are used to inform the microcomputer 
that 


an event has occurred. At interrupt 
time, system control 
software determines 
what processing 
to perform, 
as well 
as the relative sequence in which processing 
must take 


place. 
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Programs 
related 
to external 
events are processed 
in 


an 
interleaved 
manner 
based 
on 
interrupt 
occurrence 


and priority. 
For instance, one routine 
is executing when 


an interrupt 
activates, 
signaling 
that 
a higher 
priority 


event has occurred. 
At this point, the routine 
related to 


the priority 
interrupt 
is started, 
while execution 
of the 


less important 
routine 
is discontinued 
temporarily. 
When 


the more important 
routine 
is completed, 
or temporarily 


halted 
for some other 
reason, 
execution 
of the less im- 
portant 
routine is resumed. In this manner, 
multiple pro- 
grams execute concurrently 
in an interleaved 
fashion. 
Priority-In 
a real·time 
environment, 
certain 
events re- 


quire 
more 
immediate 
attention 
than 
others 
because 
of 


their 
significance 
within the physical 
world. 
Immediacy 


is relative to other processing, 
and is determined 
by ap- 


plication 
requirements. 
The concept of immediacy 
or pri- 


ority, however, is common throughout 
all real-time micro- 


computer applications. 
In priority-based 
systems, the most 


important 
program 
(one 
that 
is not 
waiting 
for 
some 


physical 
or logical reason) 
is the one executing. 
A classic illustration 
of program 
priority 
in real·time 


systems is found in the area of plant control. When the 
plant 
begins 
to fail in a nonrecoverable 
manner, 
it is 


imperative 
that 
the 
plant 
be shut 
down 
as quickly 
as 


possible. 
For 
this 
reason, 
shutdown 
processing 
takes 


priority 
over 
all other 
system 
demands. 
Software 
pri. 


ority enforces 
this hardware 
concept 
of physical 
opera- 


tional events. 
Synchronization/Communication-Another 
common sim- 


ilarity 
in most real·time systems is the need for synchro. 


nization 
between 
various 
events 
in the 
physical 
world 


which 
are 
under 
microcomputer 
control. 
Synchroniza. 


tion 
is defined 
as the process 
whereby 
one' event may 


cause one or more other events to occur. Communication 
is the process 
through 
which data 
are sent between in- 
put/output 
(I/O) 
devices or programs 
and 
otlier 
pro- 


grams within the microcomputer 
system. 


An example of the need for synchronization 
and com- 


munication 
is a microcomputer 
system for weighing lInd 


stamping 
packages. 
One part 
of the system 
weighs the 


package, 
calculates 
pricing, 
and 
releases 
the 
package 


onto a conveyor 
belt. Price 
and 
weight 'data are com· 


municated 
to another 
part 
of the system which 
stamps 


the data 
onto the package 
after 
it arrives 
at a sensor 


station. 
Synchronization 
is demonstrated 
by the occur; 
rence 
of one 
event-package 
arrival-causing 
another 


event-package 
stamping-to 
occur. 


To 
satisfy 
real-time 
microcomputer 
software 
require- 


ments, the RMX/80 
Real-Time 
Executive 
software 
(Fig 


1) 
was designed. 
This 
program 
differs 
from 
existing 


software 
systems' 
by 
offering 
capabilities 
directly 
re- 


lated 
to 
the 
single. board 
microcomputer 
environment 


in which it operates. 
These capabilities 
have two major 


bottom·line 
benefits compared 
with equivalent 
minicom- 


puter 
systems. 
First, 
the 
executive 
code 
is 
compact 


enough to allow a large number 
of real-time applications 


to be processed 
on a single microcomputer 
board. 
To 


accomplish 
this 
capability, 
its nucleus 
is optimized 
to 


reside in less than 2k bytes [ie, in a single 16k program- 
mable read.only memory (p/ROM)], 
thereby allowing up 


to 10K of onboard 
memory 
for application·related 
soft- 


ware and storage. 


Fig 1 
A typical RMX/80 system. Mul- 


tiple tasks control a given application. 
Nucleus 
controls 
execution 
of both 


user 
and 
executive 
tasks 
through 


task-to-task 
communication, 
real-time 


clock, 
priority resolution, 
and 
inter- 


rupt handling facilities. All tasks with- 
in an RMX/80-based application use 
at least some of these 
capabilities; 


other optional executive tasks include 
debugger, 
free-space 
manager, 
and 


device control for operator's 
console, 


diskette 
file system, 
analog 
subsys- 


tems, 
and 
high speed 
mathematics 
unit 
. , 


Second, the executive may be p/ROM-resident. 
When 


the microcomputer 
system 
is powered 
on, the software 


system 
(executive 
plus 
application 
programs) 
is auto· 


matically 
initialized 
and ~egins execution 
of the h,ighest 


priority 
application 
task. Typical 
maj or real-time. execu- 


tives, however, are totally random·access 
read·write 
semi- 


conductor 
memory 
(RAM) -resident, 
which 
means 
they 


must be initiali~ed 
(booted) 
from 
a peripheral 
device, 


such as diskette, 
cassette, 
or communications 
line, 
into 


microcomputer 
memory. 
The need for peripheral 
devices 


significantly 
increases 
the total cost of traditional 
real- 


time executive· based 
solutions. 


Functioning 
as a real-time ,executive. for microcomputers, 


this software 
system' provides 
facilities 
for orderly 
con- 


trol 
and 
monitoring 
of 
asynchronously 
occurring 
ex- 


ternal 
events. 
Although 
these events may 
differ 
widely 


from application 
to application, 
facilities 
are 
adaptable 


to nearly 
all processes 
where 
the 
microcomputers 
are 


used, 
including 
process 
and 
machine 
control, 
test 
and 


measurement, 
data 
communications, 
and specialized 
on- 


line 
data 
processing 
applications 
(where 
one 
or more 


terminals 
access diskette-based 
data). 
The executive 
is 


particularly 
useful 
in 
dedicated 
low 
cost 
applications 


which were not economically 
feasible before 
the advent 


of microcomputers. 
For 
example, 
consider 
the require· 


ment of gas pump control 
in a service station 
(Fig 2). 


In 
this 
station, 
a 
microcomputer 
system 
operating 


with RMX/80 
concurrently 
monitors 
and controls 
mul. 


tiple gas pumps, 
and sends price 
and volume 
informa- 
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fion to one central 
location. 
At the same time, informa· 


tion about station operation 
is being transmitted 
over a 


communications 
line to a regional 
computer. 


Individual 
tasks are developed 
independently 
to mea· 


sure 
gas /low, calculate 
and 
display 
price 
information, 
transfer 
data to the central computer, 
and monitor 
levels 


of gasoline' in ,underground 
storage. 
411 this processing 


takes place concurrently 
under program 
control. 
(Credit 


verification, 
charge 
slip printing, 
and 
billing 
can 
also 


be controlled 
by additional 
software 
tasks.) 
Efficient gas station 
operation 
demands 
that the hard· 
ware/software 
system be highly reliable. The compatible 


benefits 
of compact 
code, 
p/ROM 
residency, 
and 
self- 


initialization 
on a single-board 
microcomputer 
system all 


combine 
to ensure 
functional 
integrity. 


Software Structure 


RMX/80 
simplifies the"effort 
for: developing 
a real-time 
system, 
first, 
by 
providing 
many 
commonly 
required 


software 
functions. 
Second, 
its software, structure 
pro- 


motes efficient program 
development. 
Programmers 
who 
are familiar 
with structured 
programming 
will find tasl<; 
, 
- 
••. 
I 


orientation 
both 
natural 
a,nd easy ;to, ~se. 


Tasking 
means that a larger 
program. is divided 
into 
a number 
of smaller, 
logically 
independent 
programs 
or 


tasks. The key is to identify' functions 
that 
may occur 


concurrently. 
For 
example, 
consider 
the tasks 
required 


for a terminal 
handler-real-time 
asynchronous 
I/O 
be· 
tween an operator's 
CRT terminal 
and the executive. 


Input 
Handler Task-One 
task must be ready to accept 


a data character 
from the terminal 
at any time. This is 
done' by responding 
to 
an 
interrupt 
signal 
from 
the 
terminal 
and then accepting 
the dab 
cnantcter. 
The task 


immediately 
passes the input 
character 
to a subsequent 


task automatically 
imd then goes back to wait for an- 


other in~errupt. ' 
, 


Line BuDer Task-As 
character~ ,are received 
f~om the 
input"handler 
~hey must be pla~ed" intp a b'-l~er to form 


a line. Eventually, 
the buffer will be filleq or the logical 


end-of:line 
w'ill be signaled 
by a carriage 
return 
char- 
acter. At this pi>int, the line buffer must be sent to some 
other 
task for processing. 


Echo 
Driver 
Task-For 
a 
full-duplex 
terminal, 
it 
is 
necessary 
to return 
each input character 
to the terminal 


for display 
on the CRT screen. 
This 
task 
waits 
for ,'it 


character, 
which could be sent by either 
the line buffer 


or input 
handler ,task, and then sends the character 
,to 


the terminal. 
It then waits for the next character. 
Note'that 
input handler 
and echo driver are described 


as waiting 
for 
an event. 
Within 
the 
RMX/80, 
that 
is 


literally 
the case. 'While 
they wait, however, ',sYstem re- 


sources are available 
for other tasks, 
uch as that of the 


line 
buffer. 
Thus, 
effective 
processing 
may 
occur 
con- 


currently 
with 
hecessary 
waiting 
periods. 
Notice 
also 


that a number 
of other tasks may also be active within 


the system. In fact, the greater 
the number 
of tasks run- 


ning concurrently, 
the more effectively system resources 
are 
used. 
Concurrent 
operation 
eliminates 
many 
time 


wasting 
procedures 
from 
a 'real-time 
system. 
For 
ex- 


ample, 
the' executive 
can 
eliminate 
the need 
for many 
timing 
loops where the processor; simply executes' a no- 


operation 
instruction 
repeatedly 
while 
waiting 
for 
an 


event to occur. 


Fig 2 
Microcomputer control for gas pump automa- 


tion, In this example, executive-based 
system simul- 


taneously controls two pumps, displays information on 
operator's 
console, and ,communicates 
with regional 


computer. At a given time, more or fewer functions 
could be operating 
concurrently, 
Syste'm expansion 


can 1 be 
easily 
accomplished 
by adding 
tasks 
and 


modular hardware 


Within 
the executiv~, tasks not only are logically 
in- 


dependent, 
they are also physically 
independent, 
actually 
contendi,ng with each other for the use of the processor 
and other 
system resources. 
The executive 
resolves 
this 


contention 
based 
on ithe priority, of, each task. 
, 


In the terminal 
handler 
example, 
it is clear that 
the 


input' handler 
must have highest 
priority, 
since accept· 
able. performance 
cannot tolerate the loss of data. Second 


highest priority 
is gi)len to the echo driver, 
so that data 


appearing 
01) 
the 
scre~n 
r,,,,main coordinated 
with 
the 


input. Lowest priority 
goes to the, line buffer, since that 


function 
does not depend 
directly 
on an external 
asyn- 


chronous 
event. There 
are 
no particular 
real-time 
con· 
straints, on the line buffer 
as long 
as the 
input 
char, 


acters ,are eventually 
processed. 


It is possible 
to wr,ite the 
entire 
terminal 
ha,!pler 
as 


a single larg~ task instead 
of as several 
smaller 
tasks. 


However, consideration 
must be given other high priority 


tasks 
operating 
within 
the 
system 
which 
may 
not 
be 


able to gain 
control 
while a low priority 
portion 
of the 


terminal 
hal)dleli, such as the line ,huffer, task, is execut- 


ing. Therefore, 
tasks assigned 
as high 
priority 
are gen· 
erally kept as short 
as possible. 
If the terminal 
handler 
were written 
as one large task, it could tie up the entire 


processing 
system 
for a relatively, trivial 
function. 


Two task states have been implied-running 
and wait- 


ing. A running 
task is always the task which currently 


has the highest priority 
and is not suspended 
or waiting. 


A waiting task remains 
in the-wait 
state until it receives 


a message or an interrupt 
for which it is waiting or until 


a specified time period has passed. The wait period 
can 


be timed 
using the system clock. 
A running 
task may suspend itself on some other task 


in the system. A suspended 
task cannot 
begin execution 


again 
until 
some running. 
task orders 
it to resume. 
As 


an example, 
a password 
routine 
might 
temporarily 
sus· 


pend ihe echo driver 
of the terminal 
handler 
so that the 


password 
is not displayed. 
(The password 
routine 
must 
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Fig 3 
System 
message 
exchanges. 


In intertask 
communication 
(a) task 


1 sends 
a message 
to an exchange, 


where it is held until task 2 requests 
message 
via 
accept. 
In 
intertask 


communication 
with delay 
(b), task 


2 waits for a message 
from task 
1 


until data 
are 
available 
or 
until a 


certain 
time 
period 
has 
passed, 


whichever 
occurs 
first. In task con- 


trol (c), any task 
may suspend 
or 


resume 
any other task. 
In interrupt 


processing 
(d), an 
1/0 
interrupt 
is 


transformed 
into a message 
that task 


1 
receives 
via 
a 
wait 
command. 


Task 
1 then 
performs 
appropriate 


interrupt 
processing 


SYSTEM STOAAGE 


TASK LOCAL STOllAGE 


fREE SPACE 


Fig 4 
Memory utilization. 
RMX/80 nucleus, 
de- 


vice control task, and free-space 
allocation 
mod- 


ules are linked with user tasks to form a real-time 
system. Although executive 
may be RAM-resident, 
it is designed 
to reside in plROM and uses RAM 


only for temporary 
storage 
and free space. 
User 
tasks 
are 
provided 
by user 
at generation 
time. 
RAM may be used by RMX/80 and all associated 
tasks for temporary 
storage, 
inclUding stack. 


remove 
the password 
from 
the line buffer, 
or it will be 


displayed 
as 
soon 
as 
execution 
of 
the 
echo 
driver 
is 


resumed.) 


A task may also be in the ready 
state. A ready 
task is 


one that would be running 
except that a task with higher 
priority 
temporarily 
controls 
the 
system 
resources. 
The 


executive 
maintains 
a list of all tasks 
that 
are 
ready 
to 


run. 
The 
next 
task 
to be 
run 
is always 
the 
task 
with 


the highest 
priority 
in the ready 
list. 


The 
running 
task 
relinquishes 
its control 
of the 
sys- 
tem by 


(1) 
Putting 
itself into a wait state 


(2) 
Suspending 
itself 


(3) 
Sending 
a message 
to a higher 
priority 
task, which 


if it has 
the highest 
current 
priority, 
becomes 
the 
run- 


ning task 


(4) 
Being 
preempted 
by an interrupt 
to a higher 
pri- 


ority task 


In 
the case 
of an 
interrupt, 
the 
executive 
saves 
the 
status 
(contents 
of registers, 
etc) 
of the interrupted 
task 
so that it will be restarted 
correctly. 


Tasks communicate 
with each other 
by sending 
messages 
(Fig 3). The sending 
task constructs 
the message 
to be 
sent 
in RAM 
or 
uses 
a previously 
assembled 
message. 
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Fig 5 
Consumer 
task 
flow. 


Consumer 
task 
performs 
ini- 


tialization and then drops into 
cyclic loop, alternately waiting 
for messages, performing func- 
tions 
requested 
by message, 
and sending an acknowledge- 
ment in form of a response 
message 


The sending task then issues a SEND command 
that posts 


the address 
of the message 
at an exchange. 


An exchange 
is simply a set of lists maintained 
by the 


executive. The first list contains the addresses of messages 
available 
at that exchange. 
The second list consists 
of a 


list of tasks 
that 
are 
waiting 
for messages 
at that 
ex- 


change. When a task enters a wait state, it specifies the 
exchange 
where it expects eventually 
to find a message. 
The task may wait indefinitely, 
or it may specify that it 


will only wait a specific period 
of time before resuming 


execution. 
Messages, together 
with the exchange 
mechanism, 
pro- 


vide for automatic 
intertask 
communication 
and also for 


task synchronization. 
For example, 
a message to a par· 
ticular 
task may specify 
that 
the task is to send are· 


sponse 
to a certain 
exchange. 
Thus, 
the 
original 
task 


may 
request 
an 
acknowledgement 
response 
to 
its meso 


sage, or it may specify that a message 
is to be sent to 


a third 
task. 
RMX/80 
treats 
interrupts 
like 
messages, 


the only difference 
being that interrupts 
have their 
own 


set of exchanges. 
Note that the sending and receiving 
of messages classi- 


fies tasks into two types--message 
consumers 
and meso 


sage producers. 
A consumer 
task waits 
for a message, 
performs 
an 
action 
based 
on 
the 
message, 
and 
then 


returns 
to the 
wait 
state 
until 
another 
message 
is reo 


ceived. A producer 
task initiates 
its function 
by sending 


a message to another 
task, waits for a response, and then 


sends another 
message. Figs 5 and 6 graphically 
illustrate 
the processing 
within these two tasks. The distinction 
be- 


Fig 6 
Producer 
task 
flow. 


Producer 
processing 
flow is 


opposite to that of consumer 
task. Instead of passively re- 
acting to requests 
from other 


tasks, producer task issues re- 
quests 
to 
which other 
tasks 


must respond 


tween consumer 
and producer 
tasks is relative since many 


tasks act as both consumer 
and producer. 


RMX/80 
is supplied as a library 
of relocatable 
and link- 


able 
modules. 
These 
modules 
are 
added 
selectively 
as 


required 
when the user.supplied 
tasks are passed through 


the link 
program. 
Only modules 
actually 
requested 
by 


the application 
are linked 
in. For example, 
if the appli. 
cation 
program 
does not specify 
use of the 
free-space 


manager, 
that 
module 
is not linked 
into the system. 


One module, 
the nucleus, 
provides 
basic 
capabilities 
(concurrence, 
priority, 
and 
synchronization/communi. 


cation) 
found 
in all real·time 
systems. 
Additional, 
op- 


tional 
modules 
may 
be configured 
with 
user 
programs 
(tasks) 
to form a complete 
application 
software 
system. 


These modules 
include: 


Terminal 
handler-Providing 
real· time 
asynchronous 


I/O 
between 
an operator's 
terminal 
and tasks 
running 


under 
the RMX/80 
executive, 
the handler 
offers a line· 
edit feature 
similar 
to that 
of 
ISIS·II 
and an additional 


type·ahead 
facility. 
(ISIS-II 
is 
the 
supervisory 
system 


used on the Intellec 
Development 
System.) 


Free-space manager-This 
module 
maintains 
a pool 
of 


free RAM and allocates 
memory 
out of the pool upon 


request 
from 
a task. In addition, 
the manager 
reclaims 


memory 
and returns 
it to the pool when it is no longer 


needed. 


Debuggel'--Designed 
specifically 
for 
debugging 
soft- 


ware running under the RMX/80 
executive, the debugger 


is used by linking it to an application 
program 
or task. 


Thus, it can be run directly from the single.board 
com· 


puter's 
memory. 
In 
addition, 
an 
in-circuit 
emulator, 


such as ICE-80, can be used to load 
and execute the 


debugger, 
providing 
all 
resources 
of the 
Intellec 
de· 


velopment 
system to simplify 
debugging 
effort. 


Analog interface handlers-Consisting 
of RMX/80 
tasks, 
these handlers 
provide 
real-time 
control 
for 
SBC 711, 


724, 
and 
732 
systems. 


Diskeue 
file 
systems-Giving 
RMX/80 
users 
diskette 


file management 
capabilities, 
the diskette 
driver 
allows 
users to load tasks into the system and to create, access, 
and delete files in a real-time 
environment 
without 
dis· 


rupting normal processing. All file formats are compatible 
with ISIS·II for hoth single and double density systems. 


In 
addition 
to application 
program 
module 
or task 


requirements, 
the user also supplies a set of generation 


parameters. 
These 
parameters 
are 
a set of tables 
that 
inform 
the executive 
of the number 
of tasks 
and 
ex- 


changes in the system. Fig 7 illustrates the system gener- 
ation process. 


The significance of RMX/80 
to software design parallels 
the significance 
of the single. board 
computer 
to hard- 


ware design. Microcomputers 
allow designers without ex. 
tensive experience 
in digital 
systems to bring 
computer 


processing 
power 
into their 
applications. 
Similarly, 
the 


executive 
relieves the hardware 
designer 
of much soft- 


ware design required for real·time applications. 
Designed 
to facilitate growth, since new software needed to support 
hardware 
expansions 
can be supported 
easily by the ad- 


dition 
of new tasks, this executive also substantially 
re- 


Fig 7 
Target microcomputer system. 


Contiguration parameters 
are 
linked 


together with appropriate RMX/80 
and 


user task modules. Resulting program 
is then transterred to its target SSC 
80 system via programmed p/ROMs 
or is debugged using in-circuit emula- 
tion and then transterred 


duces recurring 
costs because it requires 
a mInImUm of 
memory and does not require 
peripheral 
bootstrap 
load- 


ing devices. RMX/80 
results in economical, 
shorter, 
and 


more flexible software 
development 
efforts when design. 
ing, building, 
and verifying 
real-time 
user applications. 
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Introducing the RMX/86™realtime, 
multitasking, 
16·bit operating system 


"Now we have a situation in which electronic intelligence 
is spreading to more and more 


places, and in addition, the application sophistication 
at each of these places is growing as well. 


So, when we multiply 
what it takes to program all the new microcomputer 
products so that 
they can be applied, and calculate what that means in terms of how many computer program- 
mers wilJ be needed by 1990, we come out with a requirement 
for over one million 
computer 


programmers!" 
Excerpted from a speech by Andrew S. Grove, President, Intel Corporation, 
given before the New York Society of Security Analysts, 
January 24, 1980. 


A 


s production 
technologies 
such as VLSI (Very 


Large 
Scale Integration) 
proliferate- 
with 


their 
greater 
levels 
of density-the 
use of 


low-cost 
microcomputer 
hardware 
to solve 


increasingly 
complex 
application 
problems 
has creat- 


ed a crisis in software. 
A partial 
solution 
to the pro- 


grammer 
shortage 
would be the creation 
of "building 


blocks" 
for system 
develo·pment. 
It is this modular, 


building 
block concept 
upon which the RMX I 86 Op- 


erating 
System 
is constructed. 


This 
modular 
operating 
system 
for 
Intel 
16-bit 


microcomputers 
allows custom operating systems to be 


assembled 
largely 
from 
off-the-shelf 
software 
com- 


ponents. 
Such systems 
when needed in OEM micro- 
computer 
applications, 
pose problems-rarely 
can an 


OEM afford man-years of effort to develop the intimate 
familiarity 
with the hardware 
that's 
needed to design 


executive software. But with Intel's RMX/86 
system he 


won't have to. 
In addition, this second-generation 
16-bit system adds 


error handling flexible command-line 
decode, and other 
advanced OS capabilities 
to previous options available 


on the mature RMX/80 
package. 


All real-time multitasking 
systems require executive 


software 
to manage 
the resources 
shared by the pro- 
grams (CPU time, memory and I/O). respond to inter- 
rupts 
and 
then 
allocate 
the 
resources 
according 
to 


established 
priorities. 
Normally, 
these 
functions 
are 


intermingled 
in an OS with higher-level 
system func- 


tions that often prove superfluous in microcomputer 
ap- 


plications. 


The RMX/86 
package combines 
all those required 
executive 
functions 
in a single 
module, 
called 
the 


nucleus. Other modules in the package tailor the execu- 
tive system 
to its application 
by adding higher-level 
operating 
system 
functions 
such as disk-file systems. 


The application 
programs 
and optional 
modules 
con- 


nect to the nucleus with simple software interfaces. 


Since the nucleus is essentially open-ended, 
it serves 


as the software foundation 
for expanding both higher- 


level operating system functions 
and varieties of appli- 
cation programs. Although most microcomputer 
appli- 
cations are dedicated, many do require such higher-level 
capabilities. 


The modular approach to system software fits in with 


the way most OEMs [and high-volume 
end users) apply 


single-board 
computers. 
They generally 
start 
with 
a 


minimum 
amount of hardware marketed 
at the lowest 
cost possible. Then, when their users are fully utilizing 
the original functions 
and are willing to buy more, the 


The RMX/86 Nucleus is the heart olthe operating system and is 
surrounded by application, 
human interlace and input/output 


facilities. 


OEM adds functionality 
by increasing 
the executive 
facilities, application 
tasks and hardware-allowing 
the 
fastest turnaround 
possible. 
To see how the RMX/86 
operating 
system 
works, 
consider 
a typical 
example. 
Sayan 
OEM develops a 
factory 
heating 
and air-conditioning 
control 
system 


with a single-board computer, 
analog I/O, 
special con- 


trol devices and operator terminal. He uses the nucleus, 
and terminal 
handler modules, plus user tasks stored in 
EPROM. 


But suppose the OEM's customer 
wants to enhance 
the system 
with, 
say, disk storage. He simply adds a 
disk controller 
board and I/O 
system 
software. 
The 
original programs could also be made disk-resident. 
If 
the original application 
had been based on a conven- 
tional executive, 
extensive redevelopment 
would have 
been necessary. 


If, on the other hand, the application had used the full 


I/O system from the start, initial sales would have suf- 
fered because the OEM's system would have been more 
costly. And if the software is not extendible, future sales 
are lost. 


The historic 
problem 
with 
conventional 
"general- 


purpose" 
operating systems is that they usually depend 
on hardware 
that the application 
would not otherwise 
need-for 
example, 
large disk systems while a typical 


OEM system 
uses no mass storage 
at all. Modular 


operating systems are designed to accommodate 
a diver- 
sity of applications 
without 
undue hardware 
imposed 


on them. 
For an even closer fit with customers 
applications, 


the 
RMX/86 
modules 
closely 
parallel 
hardware 


modularity. 
Corresponding 
to the hardware, the RMXI 86 nucleus 


manages CPU, memory and I/O sources. When linked 
to optional 
modules 
it can support 
standard 
iSBC 


devices like conscles 
and disk controllers. 
Similarly, 


users may add device driver software modules for their 
custom peripherals. All software can reside in EPROM I 
ROM if mass storage is not available. 


The RMX/86 
operating system is designed for config- 


uration, 
to user specification, 
on an Intellec 
develop- 


ment 
system. 
The same system 
supports 
application 
software development 
as well as linking and locating 


both high-level and assembly language. 


A real-time multitasking 
nucleus gives a program the 


means to monitor 
and control external 
events. 
Tasks 


running concurrently, 
using the services of the execu- 


tive are signaled 
with 
interrupts 
and the executive 
schedules resources for the tasks on the basis of priority. 
For example, 
a task trying 
to bring an oven's 
tem- 
perature under control should have a much higher pri- 
ority than a report generating task. The nucleus' 
sched- 


uler decides whether 
a running 
task should be inter- 


rupted to process data from an interrupting 
device. 


The RMX/86 
nucleus 
makes 
event-driven 
priority 


scheduling possible by monitoring 
system states, deter- 


mining task requirements, 
allocating the resources and 
gathering 
the resources 
for reallocation 
after use has 
completed. 
Resources include CPU time, memory 
and 


I/O. 
As in most priority based systems, 
the highest-pri- 


ority task that's ready to run uses the CPU; others are 
put on a ready list. After servicing an interrupt, 
the 


nucleus returns 
the CPU to the highest-priority 
ready 


task. 


A memory 
manager, built into the nucleus, 
handles 


the 8086's megabyte 
addressing 
range, insuring 
that 


memory 
is used efficiently. The memory 
manager or- 
ganizes 
memory 
into a tree-structured 
hierarchy 
of 


pools according 
to each job's requirements, 
and pro- 
vides for allocation 
and deallocation 
of memory 
from 


these pools. When the nucleus or application 
tasks re- 
quire memory, the memory manager allocates it on the 
basis of segments 
that 
are multiples 
of 16-bytes (to 


65,536 bytes) corresponding 
to the 8086's segmented 


memory architecture. 


The RMX I 86 nucleus provides three sets of facilities 


for tasks to communicate 
with one another. Each of the 


three is optimized for either data transfer, synchroniza- 
tion or mutual 
exclusion. 


Mailboxes are provided to allow tasks to send data, in 


the form of segments, 
to one another. 
Since each seg- 


ment 
is referenced 
by a description, 
of course, 
only 
pointers are moved rather than massive blocks of data. 
Semaphores offer low overhead mechanisms 
for syn- 


chronization 
operations. 
For example, 
one task 
can 


simply 
set a semaphore 
to tell another 
task that 
an 


event has happened 
("Analog data received"). 
The third 
communication 
facility 
offers a unique 
mutual 
exclusion facility. Regions are defined as a body 
of code which 
manipulates 
a shared 
resource. 
The 
RMXI 
86 nucleus insures that while one task is manip- 


ulating the resource others don't inadvertantly 
affect it. 


All intertask 
communication 
functions are accessible 


with simple calls to the nucleus. For example, to access 
a mailbox the task simply names the mailbox desired. 
The programmer 
has no need to know 
the internal 


structure 
of the mailbox, since all functions are access- 


ible through easily programmed 
interfaces. 


Another 
RMX I 86 feature, 
exceptional-condition 


handling 
makes 
error handling 
simple 
rather 
than 


elusive. Programs can be designed to manage error con- 
ditions and take the appropriate corrective action. 
First, 
there's 
an option 
to specify to the nucleus 
whether or not there should be any error handling for a 
particular 
task. A programmer can use a default handler 


to abort a task or he may program a specific course of 
action-for 
example, 
load a fresh copy of the program 


and try again. 
The 
exception-condition 
facilities 
also detect 
pro- 


gramming errors such as a wrong call to the nucleus and 
system 
problems, 
like insufficient 
memory. 
All-in-all 


the OEM will find that fault tolerance is no longer just a 
buzzword. 


Most microcomputers 
are used with a range of pe- 
ripheral devices, from serial lines to mass storage. 
The RMX/86 
I/O 
system provides the user with a 
very general file concept; that of files as a data sink or 
source. The characteristics 
of specific storage medium 


dictate the access techniques 
for a given file. For exam- 


ple, a disk file may be accessed either in sequential 
or 


random fashion, while a file accessed over a serial link 
(USARTI must be processed serially. 
Using the data sinkl source concept, the user can de- 
velop application programs without worrying about the 
physical characteristics 
of the device. 


Such device independence 
simplifies application pro- 
gramming 
and allows programs to be used with a vari- 
ety of devices. 
The 
RMX/86 
I/O 
system 
supports 
three types of 
logical files: 
Physical 
files represent 
the lowest 
interface 
level 


which 
retains 
its device-independent 
characteristics. 
Physical files provide a simple, consistent 
interface to 
all device 
drivers. 
OPEN, 
CLOSE, 
READ, WRITE, 


SEEK, and special instructions 
perform all desired I/ 0 


operations. 


Stream files provide a temporary 
data-transmission 


path between 
tasks. 
One task may write data to the 


stream file while another reads it. The 110 system per- 
forms 
the required 
synchronization 
and buffering. 


Stream files offer the user a simple mechanism 
for pass- 


ing data between 
tasks-one 
that remains 
consistent 


with 
other 
file options, 
thus 
allowing 
the user 
to 
simulate 
an extemal device while waiting for hardware 


to be built. 


Named files are used for the conventional 
data storage 


on mass-storage 
devices like floppy or hard disks for 


later access. However 
the RMX/86 
110 
system goes 


one step further by setting up a hierarchical 
directory of 


files. This feature allows the user to organize his files to 
be consistent 
with his application. 


The named-file system has another advantage: It per- 


mits file-access checking, so a user can decide which of 
his files he wants to protect and which to share with 
other users. 


Each of the file options 
can be configured indepen- 


dently; so that the user may select only the features he 
needs-nothing 
more. 
Furthermore, 
the RMX/86 
I/O system is designed to 


allow the user to easily add his own device drivers to the 
system as the need arises. 


The RMX/86 
operating system was designed to offer 


the user a wide spectrum 
of convenient 
human 
inter- 


face functions. 
For example, 
the user of mass-storage 


systems 
is provided 
display 
directory 
and copy file 


utilities. 
Additionally, 
the OEM who needs his own 


interactive 
capability 
can either 
use the 
standard 


RMX/86 
facilities or easily extend the system's human 


interface 
routines 
to meet 
his specific 
application 


requirements. 


The 
software 
crisis 
can be overcome 
only by in- 


troducing a broad base of system software functionality 
into the market, allowing OEMs to concentrate 
on their 


area of expertise. 


Intel's RMX I 86 operating system takes a major stride 


forward in providing extendible, proven tools for OEMs 
to use in creating custom 
operating 
systems 
for their 
application. 


The 
RMX/86 
operating 
system 
thus 
provides 
the 


OEM with a powerful new system building block, en- 
hancing 
the productivity 
of system 
generation. 
New 


dynamic tools like the RMXI 
86 operating system allow 


users 
to deliver 
their 
product 
into the marketplace 


much 
earlier, 
thereby 
capturing 
an important 
com- 


petitive advantage. 
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Modular multitasking executive 
cuts cost of 16-bit-OS design 


A 
modular, 
real-time 
multitasking 
operating 
sys- 


tem for single-board 
computers 
allows custom 
operating 
systems 
to be assembled 
largely from off- 


the-shelf 
software 
components. 
Such systems, 
when 


needed 
in OEM single-board 
/lC applications, 
pose 
problems-rarely 
can an OEM afford man-years 
of 


effort 
to develop the intimate 
familiarity 
with the 
hardware 
that's 
needed to design executive software. 
But with Intel's 
RMX/86 
system for iSBC 86 single- 
board 
computers, 
he won't have to. 
In addition, 
this second-generation, 
16-bit system 


added error-handling, 
flexible command-line 
decode, 
and other advanced OS capabilities to previous options 
available 
on the older RMX/80. 


All 
real-time 
multitasking 
systems 
require 
ex- 
ecutive 
software 
not only to manage 
the resources 
shared by the task programs 
(CPU time, memory and 


1/0), but also respond to interrupts 
and then allocate 
the resources according to established 
priorities. 
Nor- 


mally, these functions are intermingled 
in an OS with 


higher-level 
system functions 
that often prove super- 
fluous 
in single-board 
computer 
applications. 
The RMX/86 
OS package 
combines 
all those re- 
quired executive functions 
in a single module, called 
the nucleus. Other modules in the package tailor the 
executive system to its application 
by adding higher- 
level OS functions 
such as disk-file systems. The task 


programs 
and optional modules connect to the nucleus 
with simple software 
interfaces. 
Users can also add 


their 
own extensions. 
Since the nucleus is essentially 
open-ended, 
it can 


serve as the software 
foundation 
for expanding 
both 


the operating 
system 
and the variety 
of task pro- 


grams. Although most single-board computer applica- 
tions 
are 
dedicated, 
many 
do require 
higher-level 


capabilities. 


The OEM way 


The modular 
approach 
to system 
software 
fits in 


with the way most OEMs (and high-volume end users) 
apply single-board 
computers. 
They generally 
start 


with a minimum 
amount 
of hardware 
(often, just a 


Joseph Harakal, Software Product Manager, Intel Corp., 
5200 Elam Young Pkwy., Hillsboro, 
OR 97123. 


1. In a real-time multitasking 
system, task modules (A 


through E)can often perform their functions only after 
hardware-generated 
interrupts 
are serviced (highlighted). 


The executive in such a system provides intertask 
communications 
and synchronization. 


RMX/80 
VS RMX/86 features 


RMX/sO 
I RMX/86 


Nuclei 
Nuclei 


For iSBC 80/10 


For iSBC 80120 


For iSBC 80/30 


Optional 
modules 


Disk-file 
system 


Disk 110 


Terminal 
handlers 


Free space manager 


Analog 
1/0 handlers 


Bootstra p loader 


Debuggers 


Support 
packages 


Fortran-80 
run-time 


Basic-80 interpreter 


8080/8085 
fundamental 
support 


Free-space manager 


Excepti onal-cond iti ons 
handler 


Optional 
modules 


I/O system 


Hierarchical 
file system 


Numbered 
file system 


Internal 
file system 


Physical file system 


Interfaces 
for custom 


files and 1/0 


Human 
interface 
system 


Command-line 
decoder 


single board) to begin an application at lowcost. Then, 
when users are satisfied with the original functions 
and are willing to buy more, the OEM adds the 
executive options, tasks and hardware-with 
as fast 


a turnaround 
as possible. 


The problem with conventional "general-purpose" 
software 
systems 
is that 
they usually depend on 


hardware 
that 
the application 
may not need-for 


example, standard peripherals whereas a typical OEM 
system uses special peripherals. 
Modular OSs are 


designed to accommodate both. 
- 


What's more, a conventional system can make it 
difficult and/or awkward to use new peripherals or new 
technology, such as magnetic-bubble memory-most 
command-line 
decoders, for instance, 
are not ac- 


cessible to the user. So, a user may discover that there 
is no straightforward 
way of adding new facilities. 


Call It foundation 
software· 


For an even closer fit with single-board computer 


applications, 
the RMX/86 modules closely parallel 


hardware modularity: Each computer board contains 
program and data memory, serial and parallel I/O, 
and other generally required functions in addition to 
the CPU. Each user's 
system is expandable with 


optional modules. Frequently used devices like disk 
controllers and analog I/O are available. In addition, 
the user can connect custom devices to his system via 
the Multibus architecture. 


Corresponding to the hardware, systems software 
manages CPU, memory and I/O resources. Linked to 
optional modules, it can support standard 
iSBC de- 


vices like consoles and disk controllers. 
Similarly, 
users may add device-driver software modules for 
their custom peripherals. All software can reside in 
EPROM/ROM if mass storage is not available; other- 
wise, most of the system can be disk-resident. The 
disk·file module is suitable for such applications as 
data logging. 
The RMX/86 is designed for configuration on an 


Intellec development system according to user re- 
quirements. The same system supports task-module 
development as well as linking and locating in both 
high-level and assembly languages. It also provides 
libraries 
of frequently 
used program 
functions 
to 


minimize the amount of code the system designer 
must write and debug. 


To see how the RMX/86 works, consider a typical 


example. Sayan OEM develops a factory heating and 
air-conditioning control system having a single-board 
computer, analog 110, special control devices and an 
operator terminal. He uses the nucleus, analog-han- 
dier and terminal-handler 
modules, plus user tasks 


stored in EPROM. 
But suppose the OEM's customer wants to enhance 


the system with, say, disk storage. He simply adds 
a disk controller board and uses 110 system software. 
The original programs could also be made disk-resi- 
dent. If the nriginal application had been based on a 


2. 
The RMX/86 operating 
system treats all I/O as flles- 
a feature 
that makes It easy to add new peripherals 
and 


special flies. 


3. 
A hierarchical 
file system eliminates 
the need for 


scanning 
all the flies on a disk. If Smith Is working 
on 


Project 
A, he only has.to choose between the flies related 


to his project. 
- 


conventional 
executive, 
extensive 
redevelopment 


would have been necessary. 
If, on the other hand, the application had used the 


full I/O system from the start, initial sales would have 
suffered because the OEM's system would have been 
more costly. And if the software is not extensible, 
future sales opportunities 
are lost. 


A real-time multitasking executive gives a program 


the means to monitor and control external events. 
Tasks run concurrently, 
using communications and 


synchronization 
services of the executive (Fig. 1). 


Events are signaled with interrupts, and the executive 
schedules 
resources 
on the basis of priority-for 


example, a task trying to bring a factory under control 
should have a very high priority. The executive decides 
whether 
a running 
task should be interrupted 
to 


process data from an interrupting 
device. 


The RMX/86 nucleus 
makes 
such event-driven 


priority 
scheduling happen through resource man- 


agement. It monitors system states, determines task 
requirements, 
allocates resources and gathers them 


for reallocation. Resources include CPU time, memory 
and I/O. 


As in other systems, the highest-priority task that's 


ready to run uses the CPU; others are put on a read 
list. Finishing the high interrupt, the nucleus returns 
the CPU to the highest-priority 
ready task. 


Managing inner space 


A free-space manager, built into the nucleus, han- 


dles the 8086's megabyte addressing range, making 
sure that memory is used efficiently. The manager 
organizes memory into a tree-structured 
hierarchy of 


pools according to job requirements, 
and returns 


memory to pools. When the nucleus requires memory 
for a job, mailboxes or other functions, the manager 


provides it. Or, when a task requests memory-for 
example, to input data-the 
manager allocates it. This 


is done in segments that are multiples of 16 bytes, 
corresponding to the 8086's segmented memory. 


Tasks send data to each other through mailboxes 


which contain messages located in RAM. As in other 
systems, separate 
mailboxes are used for receiving 


and for responding. 


In the RMX/86, however, mailboxes provide several 


options, including synchronization, mutual exclusion 
(which prevents one task from destroying another 
task's data) and communications-for 
example, with 


the outside 
world-through 
modules such as the 


terminal 
handler. 
The RMX/86 nucleus also provides other means for 


communications. 
One example is semaphores-low- 


overhead mechanisms for synchronization operations, 
resource allocation and mutual exclusion that require 
a simple flag. For example, one task can simply set 
a flag to tell another task that an event has happened 
("Analog data received"). 


All these functions are accessible with simple calls 


to the nucleus. For example, just two calls are needed 
to use the free-space manager: CREATE-SEGMENT to 
request memory and DELETE-SEGMENT 
to relinquish 


memory. Likewise, to obtain an mailbox, the task 
simply names the mailbox desired. The programmer 
doesn't need to know the internal structure 
of the 


executive, since the functions are accessible through 
easily programmed interfaces. 


Errors. big and small 


Another RMX/86 feature, the exceptional-condition 


handling, makes error handling selective rather than 
all or nothing. Programs can be designed to manage 
error conditions and take corrective action. 


Multitasking design is coming to the fore, especially 


for single-board-IlC applications that usually require 
a lot more software than previous IlCs-an 
advance 


froin 
simple 
foreground-background 
programs 
to 


techniques 
based on event priorities. 


Although 
single-board 
lies 
started 
out 
in the 
mid-1970s at the low end of the OEM performance 
range, they have now reached the top in performance 
and memory capacity. As more and more OEMs and 
users take advantage of that increased capability, the 
size of applications 
programs 
grows-and 
grows. 


In the same period, the costs for developingsoftware, 


salaries and overhead have almost doubled. Moreover, 
skilled 
programmers 
have 
become 
one 
of 
the 


industry's 
most limited resources. 
No wonder that 


software costs comprise up to 80% of system develop- 
ment costs today, and that the emphasis has shifted 
from in-house software design to buying off-the-shelf 
programs. 


Because multitasking 
designs 
have to be highly 
modular, 
time-saving 
tools such as high-level lan- 


guages, program libraries and off-the-shelf software 
can be used freely to help keep development, main- 
tenance 
and expansion 
costs under 
control. 
Code 


written 
in high-level languages 
is a bargain 
today, 


compared 
to code written 
in assembly 
language: 


around $2.50 a byte vs $10 for assembly language. 
High-level code is not as compact, but it's far more 
cost-effective for the 80% of the tasks that run only 
about 20% of the time in typical applications. 


Today, there's a growing choice of languages. Struc- 


tured languages 
like PL/M and Pascal fit well into 


the "top-down" 
modular 
design technique 
used to 


divide an application into tasks. Others, like Fortran 
for mathematical 
applications and Basic for easy end- 


user programming, 
are also available. 
In general, a real-time multitasking executive offers 


a reasonable 
choice for the user who has a lot of 


software to write, must meet special requirements, 
and has no time to develop a custom operating system. 
The RMX/86 system, with its modular design, fills 
the bill to save development cost. 


First, there's an option to specify to the nucleus 


whether or not there should be any error handling 
for a particular task. A programmer can write his own 
handler either to abort a task or to program a specific 
course of action-for 
example, 
report 
exceptional 


conditions and continue with next instruction; 
load 


copy of module and try again; start alarm program. 
The exceptional-conditions support also detects pro- 


gramming errors such as a wrong call to the nucleus 
and system problems like insufficient memory. Natu- 
rally, the RMX/86 provides all normal OS functions. 
System options include a terminal handler for CRT 
and TrY consoles device drivers for Intel's floppy and 
hard-disk controllers and an integrated I/O system. 
A subsystem of the I/O system supports tree-struc- 
tured directories hierarchical 
named files (Fig. 2). 


I/O features 
are vital 


Most single-board computers are used with special 


peripheral devices, and many with other kinds of files 
and media. So, the I/O system is designed to make 
it easier to add special files, new peripherals 
and 


custom device drivers-the 
user need never feel locked 


in. 


The RMX/86 I/O system provides the user with a 


very general file concept-as 
a data sink or source. 


The characteristics 
of a specific storage 
medium 


dictate the access techniques for a given file. For 
example, a disk file may be accessed either in sequen- 
tial or random fashion, while a file accessed over a 
serial link (USART) must be processed serially. 


Using the data sink/source 
concept, the user can 


develop application programs without worrying about 
the physical device where the data will be stored. Such 
device independence simplifies application program- 
ming, and existing programs can be used with many 
devices. 
The RMX/86 VO system supports three types of 


files. 


Physical files represent the lowest interface level to 


retain device-independent characteristics. 
They pro- 


vide a simple, consistent interface to all device drivers. 
OPEN, CLOSE, READ, WRITE, SEEK and special instruc- 
tions perform all desired I/O operations. 


Stream files provide a temporary data-transmission 


path between tasks. One task may write data to the 
stream file while another reads them. The I/O system 
performs the required synchronization and buffering. 
Stream files offer the user a simple mechanism for 
passing data between tasks-one 
that remains consis- 


tent with other file options. The user can simulate an 
external device while waiting for hardware to be built. 


Named files 
are used for the conventional data 


storage on mass-storage devices like floppy or hard 


call 
rqend$lnltSt~Sk; 


CALL 
IrO I; 


do 
forever; 


msgStoken=rqrecelveSmessaQe(lfa11to~$X, 
OFFFFH,~reSP$ex,@exsval); 
call 
rqSsend$meSsage(rq$nor~aJ$th$oul, 
mSQStoKen,outSresp,@p.x$val); 
msg$token= 
rqsrecelve$messaqelout$re~r 
,OffF~H,iresp$ex,@ex$val); 
call 
rO$delete$s€gment(~sg$token,iex$v 


end; 
1* of 
00 forever 
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ena; 


4. 
RMlC/86 can easily be expanded 
with user·coded 
tasks. 


The one shown here initializes 
a user program 
by calling 


the procedure 
INIT and helps display 
messages. 


RQRECEIVE$MESSAGE 
is a system primitive 
that examines 
the 


mailbox 
to be serviced 
and places the token for the first 


message there 
(MSGsTOKEN). 
Another 
system 
primitive, 


RQsSENDMESSAGE, 
puts the token for the message Into the 


terminal 
handler's 
output 
mailbox. 
The primitive 


RQsOELETE$SEGMENT 
clears the used memory 
and returns 


It to the free-memory 
manager. 


A PGItaeaduate syst8m 


The leeeons learned since 1977 about OEM l'eqlllte, 


D18Jltafor executives have fueled the evolutloll of the 
RMX/SO Iystem. 
Thla has led to the powerful Ilew 
tuns 
of the RMX/86 Iystem. 


The RMX/80 bepn 
with a nucleus for the first 


sIDil ••board 
computer 
(iSBC SO/10). Subeeqllellt 


boards COlltained more memory and off4lred hillb•. 
throughput. 
Nucl~ 
for the three later boards were 


tlUlde Intercllanaeable, 
to act as the "software bus" 


tor tzanaportine 
applications software from one board 


to another. The RMXI86 solution is simpler: The new 
nucleua Ia hardwar.-lndependent 
so It can be used on 


future 
18 well 18 CIIll'eDt ISBC 86 boards. 


far, 
p~ntr01 
desilDers 
have generally 


telwied to add ~ming 
faciUtiee, to assure 


that _ 
do not blterfere 
Inadvertently 
with taska 


Iiandliq 
eritlcal pl'OOe88 conditions. 11a pl'OlJ'll!lldies 


dtlrlDi a chemical reaction, for example, a whole batcll 
dlII be ruined and the proeesaiq 
facilitiee may liave 


to be flushed out: 
The RHXI86 system, however, incorporates 
facU- 


lties far keeping pl'OIlramllalive. Ita nucleus contains 


8D ac8ptionaI<onditions 
support. 
Actually, a pow- 


erful error-proeeseing 
subsystem, 
It· allows sing!•. 


board eomp\lters to be made fault-tolerant 
with no 


adverse impact on throughpu~ 


disks 
for later 
access 
by another 
system. 
However, 


the 
RMX/86 
goes 
one step 
farther 
by setting 
up a 


hierarchical 
directory 
of files. 
This 
feature 
lets 
the 


user 
organize 
his 
files 
to 
be 
consistent 
with 
his 


application 
(Fig. 
3). 
The 
named-file 
system 
has 
another 
advantage: 
It 


permits 
file-access 
checking, 
so a user 
can 
decide 


which 
of his files 
he wants 
to protect 
and which 
to 


share 
with 
other 
users. 
Each of the file options 
can be configured 
independ- 
ently; 
the 
user 
may 
select 
the 
features 
he needs- 


neither 
more nor less. Furthermore, 
the user can add 


his own device 
drivers 
to the VO system. 
The 
RMXl86 
is designed 
to offer 
the user 
a wide 


spectrum 
of convenient 
functions 
(Fig 4). For example, 


the user of mass-storage 
systems 
has a display 
direc- 


tory and copy files available. 
Or, the OEM who needs 


his own interactive 
capability 
can easily 
extend 
the 


system's 
human 
interface 
routines 
to meet his require- 


ments. 


As 
/tP 
applications 
expand, 
so does 
the 
need 
for 
loaders 
that 
allow parts 
of the applications 
software 


to reside 
on disks. 
The RMX/86 
package 
provides 
a 


resident 
system 
loader that permits 
loading for either 


absolute 
or relocatable 
format. •• 
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A Small-Scale Operating System Foundation for 
Microprocesor Applications 


Abstract-Sound 
engineering methodology, 
which has long been val- 


ued in hardware design, has been slower 10 develop in software design. 
This paper uses a case study of a small real-time system to discuss sofl- 
ware design philosophies, 
wilh particuar 
emphasis on the abstract 
ma- 


chine view of syslems. It demonslrates 
how the currently popular soft- 


ware design axioms of generality and modularity can be used to produce 
a software system tbat meets severe space constraints while remaining 
relatively porlable 
across a family of microcompute •.•. These sorts of 


constraints have often been used to justify ad hoc design approaches in 
Ihe pas!. The results of the project suggest that the use of such tech- 
niques aclually make the meeting of many constraints easier than would 
a less organized approach. 
In addilion, the reliability and maintainability 


of the resuUant product is likely to be beller. 


PROCESSOR, 
as defined only by its hardware, 
is typi- 


cally not an adequate 
base upon which to build applica- 


tions software. 
Broad classes of applications 
can be ex- 


amined 
and found 
to share more than 
the hardware 
defined 


instruction 
set. To avoid the reengineering of this common func- 


tionality, we would prefer to build such common parts once and 
thereafter 
treat this base software as though it were part of the 


machine. 
For example, 
a software 
system sometimes called an 


operating 
system, 
an executive, 
a nucleus, 
a kernel, 
or some 


similar term, is often supplied with a hardware product and can 
be viewed in exactly this way. In this paper, we examine a small- 
scale system to demonstrate 
this approach 
to bridging the gap 


between the hardware and the application. 
That is, we will view 


the software as a direct extension of the hardware-a 
view which 


may indicate future directions in microprocessor 
integration 
of 


function. 
This paper is meant as both a case study of a particular system 


design and as a suggestion of the proper approach to such design 
situations 
in general. We will first discuss the abstract 
machine 


view of computer systems and attempt to demonstrate 
that this is 


a useful philosophical 
approach 
for building systems. We will 


then apply this approach 
to the discussion of a system to coor- 


dinate programs performing 
real-time control functions- 
RMX- 


80™ (18). The emphasis of the paper will be on techniques and 
methodology rather than on the particular functionality of RMX. 
Special attention 
will be given to such issues as the use of 


modularity to enhance the adaptability 
of the system and the use 


of design generality to achieve global rather than local optimiza- 
tions. 


A 


II. THE 
CONCEPT 
OF ABSTRACT 
MACHINE 


What is a computing 
"machine" 
or processing unit? We gen- 


erally identify a processing unit as a particular collection of hard- 
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ware components 
that 
implement 
the 
instruction 
set of 
the 


machine. This very physical definition of a computer dates from 
mechanical 
processors. 
Even with modern 
computers, 
before 


large-scale integration, 
it was easy to physically point at the proc- 


essing elements as distinct from memories, peripherals, 
and pro- 


grams. Continued 
integration 
of function has at least made this 


physical distinction 
more difficult 
with single chips subsuming 


processing, 
memory, 
and peripheral 
interface functions. 
Micro- 


programming 
(i.e., replacing hardwired 
instruction 
logic with a 


more elementary 
programmed 
processor) 
as an implementation 
strategy 
has logically blurred 
this distinction 
as well. That 
is, 


when the basic visible instruction set of a processor is itself imple- 
mented in terms of more primitive instructions 
it is more difficult 


to identify "the 
machine." 
It is clear that this narrow physical 


definition 
of a processor is not adequate 
for current technology 


levels and is likely to become even less viable as the technology 
continues to develop. 
Actually we have been using alternative definitions of a proces- 


sor for some time. All of the theoretical 
work in finite state 


machines, 
for example, deals with conceptual 
processors. 
Like- 
wise applications 
programmers 
seldom really regard the machine 


they program as much more than collection of instructions 
found 


in a reference 
manual-the 
physical 
implementation 
of 
the 


machine is of little concern to them. Indeed, they may never come 
physically near the hardware 
if they deal with a typical time- 
sharing system-rather, 
the terminal is the only physical manifes- 
tation of the computer such users may see. 


More to point, 
perhaps, 
are the numerous 
interpreters 
that 


have been written for languages such as Basic. Each such inter- 
preter actually produces a conceptual 
machine with one instruc- 


tion set targetted 
to a specific application. 
With standard 
com- 
piled languages such as Fortran, 
Algol, or Pascal, a higher level 
source statement 
is translated 
into the instruction 
set of the 


physical 
hardware. 
In contrast, 
interpreted 
language 
systems 


translate 
the source into the instruction 
set of some conceptual 


machine that is better suited to the running of programs written in 
the 
language. 
For 
example, 
the 
hardware 
may 
not 
provide 


floating-point 
instructions 
or define a floating-point 
data repre- 
sentation. 
In such a case it may be easier to define a machine that 


recognizes a particular floating-point 
data format with an instruc- 


tion set that includes floating operations. 
These interpreters 
are 


high-level machines that have usually been implemented 
in soft- 


ware. Likewise, it should be readily apparent that, just as these in- 
terpreters 
provide high-level machines to their associated trans- 


lators, any programming 
language, compiled or interpreted, 
pro- 


vides one to its users. 
Interpreters 
of this sort typically may examine and decode a 
stream of instruction 
values in a manner analogous 
to the hard- 


ware. Alternately, 
the new instructions 
may all be executed as 
subroutine calls using the appropriate 
hardware instruction. 
That 


is, the entire bit pattern for CALL X (where X is the address of a 
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routine that implements a part of the new instruction 
set) can be 


regarded 
as a new operation 
code rather than as the hardware 


operation CALL.In either case the programmer 
using these exten- 


sions can view the harware-software 
combination 
as though it 


were a new machine with a more useful instruction set. Micropro- 
grammed 
machines such as the IBM 5100 or Burrough's 
1700 


have simply optimized 
the performance 
of such interpreters 
or 


subroutine 
packages 
by committing 
them 
to a faster storage 


medium. 


Viewed in this light we can identify any collection of hardware 


and software that provide some well defined set of functions as 
defining an abstract machine [10),[12). This machine has an in- 
struction set that consists of the functions provided by the hard- 
ware-software 
combination. 
For a particular 
application 
it may 


be possible to view multiple such abstract 
machines by taking 


various pieces of the whole. For example, the physical machine 
provided by a set of components is just one abstract machine. It is 
of particular 
interest 
since it is the greatest 
common 
abstract 


machine that can be identified as being used by any application 
running on that computer system. A Basic interpreter 
running on 


this machine might then constitute 
a second virtual machine. A 


Basic program running on this interpreter that accepted high level 
commands 
and performed 
according to them might be a third 


level machine usable by people with no knowledge of either the 
hardware or Basic. Whenever we can identify functions of suffi- 
cient commonality 
among a number of applications, 
it may be 


worth viewing the software which provides these functions as ex- 
tensions of the base hardware 
machine which define some aug- 


mented or even different machines. Users programming 
such an 


application 
can then view this abstract machine, rather than the 


base machine as the vehicle that they are programming, 
and in 


doing so avoid reengineering the functions that it provides. Fig. I 
illustrates an example of such machines. It is important to remem- 
ber that at any time, many abstract machines may be thought of 
as existing on the same base hardware. 


III. OPERATINGSYSTEMSASABSTRACTMACHINES 


The terms operating 
system or executive have been used to 


describe software systems of widely different functionality. 
These 


machines generally provide for the management of some machine 
resources such as input, output, 
memory space, memory access, 
or processor execution time. We might then attempt to define an 
operating 
system as some collection of software modules which 


defines an abstract machine that includes resource management 
functions 
as well as the hardware 
supplied computational 
func- 


tions 
[2),[6),[8],[11). 
With such a broad 
definition, 
however, 


large-scale multi-user time-sharing 
systems and small single user 


microprocessor 
development 
systems both may claim to have 


operating systems. Clearly, the range of software systems covered 
by this definition is large, encompassing products which differ by 
orders of magnitude in complexity. Rather than become involved 
in trying to resolve this disparity, we will qualify our use of the 
term and refer to an operating system "foundation." 
That is, we 


will describe a software system which provides a minimal base for 
the construction 
of real-time 
applications. 
We will avoid the 
somewhat irrelevant question of whether the system comprises a 
complete "operating 
system." 
The important 
item to realize from the above discussion is that 
any operating system functionally enlarges the processor seen by 
the programmer. 
The functions that it provides become as much a 


part of the machine's 
functionality 
as jump instructions. 
Indeed, 


it is functionally unimportant 
to the user desiring to read from a 


file whether it requires a single hardware 
instruction 
or a large 
software 
routine 
to accomplish 
it. 
In terms 
of the abstract 


machine discussion above, we will examine a software package 
which defines an abstract 
machine that includes functions 
re- 
quired to coordinate 
programs performing 
real-time control ap- 
plications (1),[9),[12). 


The key overall requirement of the operating sytem foundation 


that 'we discuss in this paper will be that it supply a minimal cover- 
ing set of functions 
to permit 
coordination 
of asynchronous 


tasks. To determine this set we will need to further examine the 
needs of its users and environment 
of its use. In describing this 


foundation, 
we are defining an abstract 
machine that must be 


programmed 
to be of use; that is, like the instruction 
set of the 


base machine 
the foundation 
by itself performs 
no work but 


rather provides an environment 
within which useful tasks can be 


fun. 


We should note, here, some of the limitations 
of the system 


which differentiate 
it from large-scale operating systems. First, it 


is not primarily intended for a multi-user environment, 
particu- 
larly because the underlying hardware does not provide the neces- 
sary support to protect users from one ~nother. Also, it will often 
be used to control functions of specializ~d devices and therefore is 
"close" 
to the I/O devices. That is, it does not supply the sort of 


high level I/O control system which is often present in larger sys- 
tems for controlling 
more conventional 
I/O devices. Finally, it 


does not assume a backing store from which program 
overlays 


can be loaded (but it can easily support such an extension). 


IV. DESIGNCONSIDERATIONS 


A. 
Use Environment 


The foundation 
system we will describe is RMX-80 [5] which 


was designed to be used with members of Intel's Single Board 
Computer (SBC) family of products. This family includes a wide 
range 
of bus compatible 
processor, 
memory, 
and 
peripheral 


boards. 
Of most interest 
to this discussion 
are the processor 


boards which are based on the Intel 8080 or 8085 microprocessors 
and include varying amounts of on-board ROM and RAM mem- 
oryand 
I/O interfaces. In addition, the boards vary in the sophis- 


tication of their interrupt structures and timing facilities. In terms 
of abstract 
machines we might characterize 
these computers 
as 


essentially the same machine at the processor level but different 
machines at the computer 
system level. It was desired that the 


abstract machines defined by adding RMX to the underlying com- 
puters be as much the same as possible. 


During the design of RMX, we expected that its users would 


span the entire broad range of applications across which the SBC 


hardware was being put to use. This implied that it might see uses 
ranging from minimal single board systems that functioned 
as 


single device controllers to complex multiboard 
applications 
im- 


plementing involved real-time process or industrial control func- 
tions. In particular we expected that many user-built I/O boards 
and peripherals would be used with the system. It was important 
for us to allow full use of these unknown devices with RMX while 
still providing as much assistance as possible in the building of the 
controlling software systems. 
As is the case with most processors, the concrete (i.e., physical) 


machines represented 
by the SBC family do not themselves in- 


clude any facilities to permit multiple asynchronous 
functions to 


be programmed, 
to provide for the coordination 
of such func- 


tions, or to provide time information 
needed for real-time ap- 


plications. 
Typically, users of these products 
have directly pro- 


grammed 
these functions 
in an ad hoc manner within their ap- 


plications. An examination 
of the sorts of functions necessary to 


such applications reveals that at the very least this reengineering is 
a waste of resources. Worse is the high probability of error in pro- 
gramming such critical functions. 
The SBC hardware 
products 
were designed to eliminate 
the 


complexities 
of board 
engineering, 
particularly 
for those users 


without the necessary expertise to handle the task, by functionally 
integrating 
individual 
components 
into complete 
boards. 
The 


programming 
of functions to coordinate 
parallel software activi- 


ties is, likewise, an area which should be carefully engineered in 
order to avoid subtle errors. The development of RMX was there- 
fore viewed as a process of functional 
integration 
analogous 
to 


the integration of LSI components 
into boards. That is, just as a 


well designed board relieves the user of component level hardware 
engineering, 
RMX relieves the users of low-level software engi- 


neering. 


B. System Requirements 


The hardware environments 
and anticipated 
uses of RMX de- 


fined a stringent set of requirements 
for it. Foremost among these 


were its memory constraints; 
indeed, 
for the anticipated 
uses, 
memory size considerations 
dominated execution speed ones over 


a considerable 
range. Since we expected applications 
that would 


reside entirely on a single board with 4K bytes of PROM, 
the 


maximum size of the RMX foundation 
code was set at half of this 


or 2K bytes. Further, 
unlike larger minicomputer 
systems, many, 


if not most, applications of the SBC boards would not have avail- 
able any mass storage or other program 
loading device. It was 


thus important 
that RMX be designed to be ROM (or PROM) 


resident and capable of automatically 
initializing the system when 


powered on. 


We also anticipated 
that the expertise of many RMX users 
would be in areas other than programming systems. We therefore 
felt that the RMX machine needed to provide a fairly simple set of 
concepts, avoiding where possible those constructs most likely to 
cause errors. For example, we felt that a very frequent source of 
programming 
difficulty 
lay in dealing 
with interrupts. 
Many 
latent errors in programming systems stem from the occurrence of 
an interrupt 
at an unexpected time. We therefore decided to at- 


tempt to minimize the need for users to deal with hardware inter- 
rupts or with the interrupt-like 
occurrences found in many mini- 


computer operating systems. At the same time we had to accom- 
modate the needs of the sophisticated 
user who still desired to 


take advantage of RMX but had a specific need to directly control 
the hardware via the interrupt 
facility. 
Finally, to define the general functionality 
of RMX we exam- 


ined its anticipated 
applications. 
Real-time 
applications 
com- 


monly need to perform a number of tasks of differing importance 


logically in parallel, with preference always being given to execut- 
ing the most critical ones first. While these tasks may be relatively 
independent, 
they may need to periodically 
synchronize 
them- 
selves with one or another distinct task or with the outside world. 
For the latter, interrupts are the usual hardware supplied mecha- 
nism. Some tasks may also need to communicate 
data with one 


another. 
For example, a task servicing a sensing device may take 


readings from the device which need to be communicated 
to two 


tasks: one task which reacts to the reading by controlling 
some 
other device, and another task which logs or tabulates the read- 
ings. Ranked in order of importance these might be control, sens- 
ing, and logging. Finally, the tasks must have the ability to con- 
trol themselves relative to real-time, either by delaying their exe- 
cution for certain periods or by guaranteeing 
that they are not in- 
definitely delayed by, for example, a faulty device. 


Requirements on the system design were also generated by con- 
siderations 
internal to the design project. 
One of these was the 


need to provide a single RMX abstract machine on a variety of 
underlying SBC boards. While separate versions of RMX for each 
board could have been designed with the same external appear- 
ance, this approach would have led to an unnecessary amount of 
internal engineering. Additionally, 
without careful initial design, 
the differences 
in the base hardware 
would have had visible ef- 


fects on the RMX abstract machine for each of the boards. This 
requirement 
demanded 
that we partition 
the structure 
of RMX 


into two parts. One part would implement those aspects which 
were independent 
of the particular 
hardware. 
The second part 


would interface the first part to the underlying hardware 
of the 
specific boards (7]. 


We also wished to minimize the software development costs by 
applying the best available software engineering techniques. 
His- 
torically, tight space constraints 
have often led to a very ad hoc 


approach 
to software 
design in the belief that more generally 


designed 
external 
features 
or 
more 
modularly 
built 
internal 
designs would lead to inherently larger systems. As a result of this 
philosophy, 
each needed function 
is designed to be as small as 


possible. Unfortunately, 
while each function may be locally opti- 
mized, it is possible that the overall design suffers from duplica- 
tion or overlap between such individual elements. Current work 
in programming methodology stresses modularity, generality, and 
structure 
(most often 
for their side effects in producing 
more 


maintainable, 
less error prone systems). 


We felt that there was more to gain, both in development cost 
and space performance, 
by avoiding optimized specialization 
of 


function in favor of more general designs (17). This reduced the 
number of separate functions that RMX had to supply. The re- 
sulting external design therefore has a single mechanism that pro- 
vides task communication, 
synchronization, 
time references, and 
standard 
interrupt-like 
control. 
To do so it incorporates 
the 


operating system design approaches favored in much of the mod- 
ern computing 
literature. 
Likewise, the internal 
structures 
are 


highly modular and designed to be as uniform as possible so as to 
avoid replicating similar, but nonidentical 
internal management 
routines. 


V. THE RMX MACHINE 


B. General Concepts 


The abstract 
machine 
defined 
by RMX 
augments 
the base 


microprocessor 
by introducing 
some additional 
computational 


concepts. We define a task to be an independently executable pro- 
gram segment. That is, a task embodies the concept of a program 
in execution on the processor. RMX permits multiple tasks to be 
defined 
which 
can 
run 
in a parallel, 
or 
multiprograrnmed, 


fashion. 
That is, RMX makes individual tasks running on one 


processor appear to be running on separate processors by manag- 
ing the dispatching of the processor to particular tasks. The reg- 
isters on the processor reflect the activity or state of the running 
task. Other tasks may be ready to execute but for some reason 
have not been selected to run yet and so have their processor 
states saved elsewhere in the system. From the point of view of the 
program that is a task, execution proceeds as though it were the 
only one being run by the processor. Only the apparent speed of 
execution is affected by the multiprogramming. 
From the point of 


view of the system, every task is always in one of three states: run- 
ning, ready, or waiting. The task actually in execution is running. 
Any other task which could be running but for the fact that the 
system has selected some other task to actually use the processor, 
is ready. Tasks which are delayed or stopped for some reason are 
waiting, as will be discussed below. 
Each task is assigned a priority which determines its relative im- 


portance within the system. Whenever a decision must be made as 
to which task of those that are ready should be run next, the one 
with the highest priority is given preference. 
Furthermore, 
in the 


'spirit of unifying mechanisms, the same priority scheme replaces a 
separate mechanism for disabling interrupts. 
Interrupts 
from ex- 


ternal devices are logically given software 
priorities. 
If the ap- 


plications system designer deems a particular task as of more im- 
portance than responding to certain interrupts, he can specify this 
by simply setting the RMX priority of that task to be higher than 
the RMX priority 
associated 
with those given hardware 
inter- 


rupts. It is thus possible to maintain a high degree of control over 
the responsiveness required for various functions. 
As mentioned 
above, tasks may desire to communicate 
infor- 


mation to one another. 
To this end the RMX machine defines a 


message to be some arbitrary 
data to be sent between tasks. To 


mediate the communication 
of messages it defines an exchange to 


be the conceptual 
link between tasks. 
An exchange 
functions 


somewhat like a mailbox in that messages are deposited there by 
one task and collected by another. 
Its function is complicated by 
the fact that a task may attempt 
to collect a message at an ex- 


change that is empty. In such a case the execution of that task 
must be delayed until a message arrives. Tasks that are so delayed 
are in the waiting state. We chose this indirect communication 
mechanism over one which directly addresses tasks because it per- 
mits greater flexibility in the arrangement 
of receiver and sender 


tasks. The anonymity of the receiving task implies that the sender 
need know only the interface specification 
for a function to be 


performed 
via a message to a particular 
exchange. The task or 


tasks which implement 
that function 
need not be known and 


hence may be conviently changed if desired. 
The conventional 
mechanism used by programs to communi- 


cate with external devices is the interrupt. 
Unfortunately, 
inter- 


rupts are by nature 
unexpected 
events and programming 
with 


them tends to be error prone. The essential characteristic of an in- 
terrupt is that a parallel, asynchronous 
activity (the device) wishes 
to communicate 
with another 
activity (a program). 
Since this 


communication 
is essentially the same as that desired between 


separate software tasks it seems conceptually 
simpler to use the 


same message and exchange mechanism for it. The unification of 
all communications 
functions 
is analogous to the idea of stand- 


ardized 
I/O 
found 
in systems such as UNIX 
[17). The RMX 


machine eliminates interrupts 
by translating 
them into messages 
which indicate that an interrupt has occurred. These messages are 
sent to specific exchanges associated with particular 
interrupts. 
Tasks which "service interrupts" 
do so in RMX by attempting to 
receive a message at the appropriate 
exchange. Thus, prioritized 


nested interrupts are easily handled. An advantage of this unfied 


treatment 
of internal and external communication 
is that hard- 


ware interrupts can be completely simulated via another software 
task. This facilitates debugging and permits easy modification 
of 
a system by allowing rather arbitrary insertion of tasks into a net- 
work of communicating 
tasks and devices. 


Note that with this scheme unexpected interrupts do not cause 


particular difficulty. For example, if the servicing task is still busy 
with some previous message, the interrupt 
message will be left at 


the exchange and will not affect the task until it is ready for an- 
other interrupt; 
i.e., until it waits at the exchange. In an applica- 


tion designed to properly handle the actual interrupt rate, the task 
will service interrupts quickly enough to always be waiting when 
the next one occurs. In this case, response to an interrupt 
is im- 
mediate. Thus this mechanism provides no loss of facility relative 
to the usual interrupt 
scheme but it does make the proper con- 
trolling of such events simpler. Multiple occurrences of the same 
interrupt which indicate the processor has fallen behind in its ser- 
vicing are logged as such by a message which indicates that inter- 
rupts may have been lost. These interrupts do not, however, dis- 
rupt the running task or complicate programming. 


The last concept embodied in the RMX abstract machine is that 


of time. The RMX machine defines time in terms of system time 
units. It then permits tasks to delay themselves for given periods 
of time so that they can synchronize themselves with the outside 
world. It also permits tasks to guard against unduly long delays 
caused by attempting 
to collect a message at an empty exchange 


by limiting the length of time that 
they are willing to spend 
waiting for some message to arrive. 


B. Data Objects and Functions 


These concepts are realized in RMX by introducing 
some new 


data objects and instructions. 
Just as the base processor can deal 


directly with such data objects as 8 bit bytes or unsigned integers, 
the RMX abstract machine can deal directly with the more com- 
plex data objects: task, message, and exchange. 
Each of these 


data objects consists of a series of bytes with a well defined struc- 
ture and may be operated upon only by certain instructions. 
This 


is completely analogous, 
for example, to a machine that permits 


direct operations 
on floating-point 
data objects which consist of 


four bytes with a particular 
internal 
structure 
to represent 
the 


fraction, exponent, and signs. In each case there are only certain 
instructions that can be used correctly with the object and the in- 
ternal structure 
of the object is not of particular 
interest to the 


programmer. 


The new instructions 
provided by RMX are: SEND, WAIT, 
AC- 


CEPT, 
CREATE 
TASK, 
DELETE 
TASK, 
CREATE 
EXCHANGE, 
and 


DELETE 
EXCHANGE. 
The create instructions 
accept blocks of free 


memory and some creation information 
to format and initialize 


the blocks with the appropriate 
structure. 
Each corresponding 


delete instruction accepts one of the objects and logically removes 
it from the system. The remaining operations 
are of more direct 
interest to the operation 
of the RMX machine. 


The WAIT instruction 
has two operands: 
the address of an ex- 
change from which a message is to be collected and the maximum 
time (in system units) for which the task is to await the arrival of a 
message. The result of the operation is the address of the message 
which was received. A special message from the system indicates 
that the specified amount of time elapsed without the arrival of a 
normal message. From the programmer's 
point of view this in- 
struction simply executes and returns the specified result. Actual 
execution of the instruction will involve the delaying of task exe- 
cution if no message is available, by queueing it in a first-come- 
first-served manner at the exchange. Any such delay is not visible 


to the programmer, 
however. This approach unifies the commun- 


ication and timing aspects of the design. Inlirectly 
provides reli- 


ability in the face of lost events due to hardware or software fail- 
ure. Tasks can be guaranteed 
not to be indeterminately 
delayed 


due to such failures and can thus attempt recovery from them. It 
also permits tasks to use the same mechanism to delay themselves 
for given time intervals by waiting at an exchange at which no 
message will ever arrive. 
The ACCEPTinstruction 
is an alternate 
way to receive a mes- 


sage. It has a single operand specifying the exchange from which 
the message is to be received and immediately returns either the 
next message at the exchange or a flag indicating that no message 
was available. The task is never delayed to await a message in the 
ACCEPToperation. 


SENDalso has two operands: 
the address of a message and the 


address of an exchange to which the message is to be sent. The in- 
struction queues the message in a first-come-first-served 
manner 
at the exchange if there is no task already waiting there. If a task is 
waiting at the exchange then the instruction binds the message to 
the task and makes the task eligible to execute on the processor. 
When the receiving task resumes actual execution the address of 
the message will be returned to it as the result of its WAITinstruc- 
tion. 


VI. THE RMX IMPLEMENTATION 


A. Methodology 


In this section and the next, we consider some (but certainly not 


all) details of the actual implementation 
of the system as illustra- 


tions of the design of such software products. We turn first to the 
methodology 
applied to the effort and then to some samples of 


the mechanisms. 
To provide the abstract 
machine just described and meet the 


other requirements 
for the system, RMX was implemented 
as a 


combination 
of ROM resident 
code and some RAM resident 


tables. Just as a hardware designer uses LSI devices in preference 
to more 
elementary 
TTL 
components, 
we chose to use the 
leverage 
of 
a high 
level programming 
language 
rather 
than 
elementary 
assembly code. The system was, therefore, 
designed 


using PLM (14), Intel's high-level implementation 
language. The 


operations 
described above appear as procedure 
calls using the 


standard PLM calling sequence. The space constraints and a good 
level of internal maintainability 
were achieved by maximizing the 


modularity 
of the design. The broad independent 
functions 
of 


multiprogramming, 
communications 
and control were completely 


isolated from the board dependent timing and interrupt handling 
functions. As a result, movement of the system to a new member 
of the SBC family requires only the reimplementation 
of these 


board dependent functions. In addition, data structure of internal 
and user visible objects were generalized so that single algorithms 
could deal with any of them. Individual optimizations 
could have 


been made in the local design of many parts of the data structures 
to improve their space or time costs slightly. Such optimizations, 
however, would have cost considerably 
more in code space and 


code complexity [3]. 
The module feature of PLM was used to simulate the abstract 


data type concept [4),[13) and enforce information 
hiding [15), 
[16). That is, every data structure used by RMX is under the ex- 
clusive control of a single module. The modules supply to each 
other restricted sets of public procedures and variables. It is only 
through these paths that agents outside a module may access the 
data structures maintained 
by the module. The only assumptions 
that such outside agents may make about a module and its data 
structures are those specified by the definition of the public paths. 


HA.RDWARE 
lEVEL 


INTERRUPT 


MODULE 


HARDWARE lEVEL 


TIME 


MODULE 


As a result, so long as these interface 
specifications 
are main- 
tained, any given data structure may be reorganized by redesign- 
ing its controlling module without affecting other parts of the sys- 
tem. This approach 
improves the understandability 
of the imple- 


mentation 
and facilitates the debugging and maintenance 
of the 
system. Fig. 2 illustrates the general structure of the RMX imple- 
mentation. 
Finally, the original version of RMX was completely coded in 


PLM using the resident PLM compiler of the Intellec<!lMicro- 
computer 
Development' 
System. 
This version was functionally 
complete but slightly exceeded the space constraints, 
occupying 


about 2.5K bytes of program space. There were a couple of cases 
where the language structure of PLM did not permit the direct ex- 
pression of the best way to compile the code. For these modules, 
it was sufficient to hand optimize the code output 
by the com- 
piler. The original structure of the PLM program was maintained 
and the majority of its generated code was used intact. The final 
RMX system occupies less than 2K bytes of program space. This 
high level language approaCh coupled with selective manual opti- 
mization permitted far quicker and more error free development 
than could have been achieved using assembly language. 
The approach 
to handling interrupts 
did introduce 
additional 
software overhead. 
For a typical configuration 
of the hardware, 


the realistic minimum interrupt 
latency would be about 200 /'s. 


Using the message mechanism it is about 800 /,S. fur the targetted 
process control 
applications, 
this is entirely acceptable. 
RMX 


does make provision, however, for direct handling of selective in- 
terrupts which require better response t.imewithout disturbing the 
use of the message mechanism 
for the others. 
For normal task 
communication, 
the performance 
is relatively better. For the typ- 
ical hardware configuration, 
the transmission 
of a message takes 
about 800 /'s, which is comparable 
to the time that would be re- 


quired for any synchronization 
primitive (e.g., P and 
Vor 
en- 


queue and dequeue) on such hardware. 


B. Engineering for Hardware Dependencies 


The two functions which vary most significantly across the SBC 


product 
line are the timing and interrupt 
facilities. To accom- 


modate these variations, 
the implementation 
separates the logical 


and physical parts of these functions. 
The interrupt 
facilities are split between the module which im- 


plements the communications 
operations 
and a hardware 
inter- 


rupt handler 
module. 
The communications 
module provides a 


special "interrupt 
send" 
operation 
which performs 
the logical 


translation 
of the interrupt 
event into a message. This facility is 
independent 
of the interrupt structure of the processor board and 


remains the same in any version of RMX. The hardware depend- 
ent interrupt 
module deals directly with the hardware 
interrupt 


structure and invokes the send operation at the logical level. Only 
this module need be redesigned when generating an RMX version 
for a different SBC board. With this approach we take full advan- 
tage of the hardware vectored priority interrupt structure on high 
performance 
products and can simulate this desirable structure at 


slightly higher software cost on low performance 
products. 


The same sorts of variations are faced in providing a source for 


the system time unit. 
Again, 
one module 
provides 
all of the 


logical time functions associated with providing time delays and 
time limits to the user system. This module is independent 
of the 


type, frequency, 
or location of the physical time source. A sep- 


arate module is responsible for clocking the logical level by invok- 
ing it once every system time unit. Once again, this permits a con- 
sistent definition of time in RMX systems regardless of the sophis- 
tication of the available time source, and it limits the amount of 
reimplementation 
that is needed to support new SBC products. 


C. Example Data Objects 


As an example of the complex data objects defined in the sys- 


tem we will consider the task and exchange objects illustrated in 
Fig. 3. The task object is 20 bytes long and embodies the execu- 
tion state and status of a task. It consists of pointers used to link it 
onto various lists of tasks in the system. These lists are used to 
queue a task at an exchange, link it to other ready tasks, or keep 
track of its maximum 
delay when waiting. It also contains the 


stack pointer of non-running 
tasks which is sufficient to supply 


the remaining 
task register values when the task next executes. 
Finally, the object contains the task priority, some status infor- 
mation describing the state of the task, and a pointer to auxiliary 
information 
about the task. 


The exchange object is 10 bytes long and implements the mail- 


box concept described earlier, primarily by serving as the source 
of header information 
for lists of messages and tasks. Each of 


these singly linked lists is addressed with head and tail pointers 
located in the exchange object. 
All exchanges in the system are 


also linked together. 
The exchange objects are operated 
upon by the SEND, 
WAIT, 


and ACCEPT instructions 
of the RMX abstract machine. These in- 


structions 
generally alter the "value" 
or contents of these com- 


plex data objects. The task object is not the direct operand of any 
RMX instruction described above. Rather it is indirectly altered as 
a side effect of various instructions. 
Just as the user of floating- 


point objects on most machines needs to know the length and ex- 
istence of instances of the object, but not its internal structure, so 
the internal structure of these objects is generally unimportant 
to 


the users. 
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D. Global Versus Local Optimizations 


We have already discussed some aspects of global versus local 


optimizations 
at the overall design level in terms of avoidance of 


redundant 
features. A good example of this tradeoff in the imple- 
mentation 
is provided 
by the linked list data structures 
within 


RMX. Like many such systems there are a number 
of singly 


linked lists which must be maintained 
to reflect the status of the 
system. Local optimizations 
on the placement of links within data 
structures or in the form of the headers used for the lists would be 
guaranteed 
to save a few bytes of data space across the various 


lists. Further, the list insertion, scanning, and deletion algorithms 
could be specially tailored to the individual list structures to save 
microseconds 
of execution 
time for some operations 
on some 


lists. Indeed, anyone 
such tailored algorithm might well use less 


code space than a single more general one. 


On the other hand, many of the list operations 
are in no sense 


time critical. Generalizing 
all the list structures 
to use a single 


form replaces multiple 
algorithms 
with one, thus saving code 


space. The particular 
form can be chosen to favor those opera- 


tions that are frequent, thus limiting the impact of the generaliza- 
tion on the execution speed of the system. Perhaps most impor- 
tant, however, is that, by reducing the number of algorithms and 
structures 
used, we decrease the potential 
number of errors and 


improve the maintainability 
of the resultant product. 
Since there 


are, for example, at least six distinct singly linked structures in the 
system, we reduce overall code size and engineering cost by sup- 
porting only a single mechanism. 
We improve product reliability 


at the price of a small increase in fixed data space and a small exe- 
cution speed penalty of infrequent 
and nontime-critical 
opera- 


tions. 


It is interesting to note as an aside that this is really an example 


of software engineering: that is, applying engineering discipline to 
software development. Such discipline is highly valued and under- 
stood 
in other 
engineering 
fields. Standardized 
mechanical 
or 


electrical components 
are virtually 
always preferred 
to special 


designs; PLA's often replace random logic. Unfortunately, 
an ap- 


preciation of the overall benefits of such structure has been slow 
to develop in software 
engineering. 
Too often, 
we have seen 


special purpose designs and overly complex structure used in pro- 


grams supposedly to save space or improve speed. The true costs 
in development time and reliability of such approaches have often 
been underestimated; 
the true time savings attributed 
to them 


often overestimated. 
The high percentage of end product cost due 


to software is finally forcing a general awareness of these issues. 


VII. LSI ANDABSTRACTMACHINES 


It seems natural at this point to ask how the abstract machine 


view of systems in general and our experience with RMX might be 
affected by the continuing development of LSI technology. Once 
we view any complex software system as defining a collection of 
abstract 
machines, 
it becomes obvious that it is simply an engi- 


neering decision as to which machines should be committed 
to 


hardware. 
We are constrained 
in this choice by the densities of 


our solid-state 
technology, 
the performance 
we desire, the ap- 


plications that we are attacking, 
and perhaps most severely, by 


our understanding 
of software systems and of the machine struc- 


tures that they require. 
We might build an entire final application (e.g., a cash register) 


as a very-high-level 
single-chip machine. 
The specialization 
of 


such a design 
would, 
however, 
severely limit its application 


beyond the one for which it was specifically meant. On the other 
hand, 
we could build exclusively bit slice microprogrammable 


machines with utmost generality but which, due to their very low 
level of functional integration, 
would have no technological lever- 


age for attacking 
complex problems. 
Actually, 
both these ex- 


tremes have their well developed roles and will continue 
to be 


reasonable 
approaches 
for high-volume 
low-cost, 
and special- 


purpose tailored systems, respectively. It is in the middle ground 
-the 
area of the traditional 
computer-that 
directions are less 


clear. 


If the 8080 type processors are generally somewhat less power- 


ful than we actually need and as a result we always build operating 
systems of some level to support 
them, perhaps some of these 


functions can be integrated into the hardware. That is, if we can 
identify a broad range of systems which include essentially the 
same 
abstract 
machine 
implemented 
in software, 
then 
that 


abstract machine is a good candidate 
for hardware 
integration. 
The engineering 
difficulty 
is in understanding 
these software 


structures well enough to confidently and correctly commit them 
to hardware. 


Attempting 
to build all of some very large and complex operat- 


ing system onto one or two chips is, no doubt, out of the question 
with current technology. 
On the other hand, the final RMX sys- 


tem which we described resides in a small amount of ROM within 
the 65K address space of the 8080 processor. Once we view RMX 
as an abstract machine, the placement of the code which imple- 
ments its functionality 
becomes immaterial. 
In particular, 
we 


could build an augmented 8080 type processor directly by defining 
the additional 
instruction 
codes of RMX as hardware operations 


and moving the RMX implementation 
into microcode 
on the 


chip. The resultant component 
would indeed be an "RMX 
ma- 


chine" 
which dealt directly with the complex data objects and 


tables described above. It would have the advantage of not using 
any of the address space for operating system code. More impor- 
tantly, 
it would not waste bus cycles and memory access time 


fetching operating 
system instructions. 
Such a machine would 


have the same advantages over a conventional one that a machine 
with floating-point 
hardware has over one without it. 


Should we then try to build the RMX machine-ignoring 
for 


the moment 
whether our hardware 
technology 
is capable of it 


quite yet? Is the simple task model of RMX sufficiently general to 
be of use over a wide class of applications? 
Is the RMX machine 


the complete tool that we would like? Clearly, the answer is not a 


wholehearted 
yes. For one example, RMX provides no isolation 


or protection 
of one task from another. 
Indeed, no solely soft- 
ware system can provide such protection 
at any reasonable cost. 


Such isolation would be desirable at the least because it would 
limit the damage that one task could do to another due to errors. 
The conclusion to be drawn, therefore, 
is not that this particular 


abstract 
machine should be built in hardware, 
but rather 
that 


some such machine would provide more of the facilities needed 
for building microprocessor 
applications 
than do current proces- 
sors. Further, 
the design principles discussed above are the ones 


that appear most likely to be fruitful in creating such a machine. 


VIII. 
CONCLUSIONS 


In this paper, we have attempted to use a case study of a partic- 


ular small operating system to illustrate both a philosophical 
ap- 
proach to viewing computer systems and some important 
aspects 


of software 
development 
methodology. 
Many of the subtle as- 


pects of desiging software to control quasi-parallel activities have 
not been discussed in detail, nor have we fully described the im- 
plementation. 
Nevertheless, we hope that this description suggests 


the practicality 
and necessity of disciplined approaches 
to soft- 
ware system design. Until software implementation 
reaches a level 


of engineering commensurate 
with that applied to other aspects of 


computer 
system design, our products 
will be very much bound 


by software costs. Only discipline and structure 
within our soft- 


ware efforts will ultimately permit microprocessor 
applications to 


reach their full potential. 
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Faster and smaller than its predecessor, the iRMX 88 real-time 
modular operating system eases the transition from 8-bit to 16-bit 
f.LCS, while supporting the 8087 arithmetic chip and other peripherals. 


Multitasking executive 
speeds 16-bit micros 


Even while it eases the transition 
from an 8-bit 


to a 16-bit world, a new operating system (OS) brings 
thoroughbred 
performance 
to the stable of modular 


systems 
software. 
The iRMX 88 multitasking 
ex- 


ecutive cuts both interrupt 
latency (the delay until 


a 
random 
event 
gets 
a 
response) 
and 
context- 


switching time (the interval during which the proces- 
sor changes from one task to another). 
Its nucleus 


is, therefore, 
faster-and 
smaller--than 
those of 


preceding 
operating 
systems. 
The 
iRMX 88 Executive 
provides 
fundamental 


multi masking 
software 
and complements 
the full- 


featured, 
multiprogramming 
iRMX 86 OS (ELEC- 


TRONICDESIGN, March 
15, 1980, p. 245). Through 


priority-based 
task 
scheduling, 
it 
concurrently 
monitors 
and controls 
multiple 
events. It provides 


real-time 
clock control, 
manages 
interrupts, 
and 


dispatches 
tasks. As an upgraded 
version of the 8- 


bit iRMX 80 Executive, 
iRMX 88 employs the same 
concepts and most of the same modules. Thus, the 
new OS offers field-proven 
and reliable 
interfaces. 


Tasks share resources 


The Executive 
will run with iAPX 88 or iAPX 86- 


based boards and supports Intel's iSBC 86/12A, iSBC 
88/40, and iSBC 86/05 single-board computera. Since 
it is fully configurable-not 
only procedure-by-pro- 


cedure, 
but 
also for all hardware 
addresses 
and 


interrupt 
levels-it 
also can be used with custom- 


designed boards that contain an iAPX 86 or iAPX 88 
processor, 
an 8259A programmable-interrupt 
con- 


troller, 
and 8253 programmable-interval 
timer, 
an 


optional 
8251A programmable-communications 
in- 


terface, 
and-perhaps 
most 
important-an 
8087 


numeric-data 
processor. 


In a multitasking 
system like the iRMX 88, several 


J.ss 
M. Irwin, Project Leader 
Intel Corp. 
5200 N.E. Elam Young Pkwy. Hillsboro, OR 97213 


tasks execute concurrently. 
A task is an independent 


program 
that 
shares 
system 
resources 
and com- 


municates 
with other tasks. Each task has its own 


stack, where the registers 
used by the task are saved 


to shorten 
context-switching 
time. 


A 
task 
communicates 
with 
other 
tasks 
via 


messages, 
which convey data and synchronization 


information. 
These messages are channeled through 


data 
structures 
called exchanges. 
A task can send 


messages 
to an exchange 
(using the RQSENDpro- 


cedure) or wait for messages at an exchange (using 
the RQWAITprocedure). 
In the latter 
case, the task 


does not execute until a message is available or until 
a certain 
length 
of time has elapsed, 
specified 
in 


terms of "system time units" (minimum 
interval 
of 


real time recognized by the system). A task that is 


,-A-s 


,~' 


1: 
Task 
slarts 
running 
because 
It is currently 
the: ready 
task 
with 
the 
highest 
priOrity 


2" Task 1$still ready but stops running because It has no longer the hIghest prtority 
3: Task wailS for a message 
4: Task receives a message or completes a delay 
5 
Task is suspended 
6: Task is resumed 


7: 
Running 
task 
suspends 
ilsell 
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not willing to wait may accept any message from 
an exchange (using the RQACPT procedure) 
if one is 


available; 
otherwise, 
the task 
remains 
without 
a 
message. 
Each task exists in one of four states: 
running, 


ready, 
waiting, 
and suspended 
(Fig. 1). A task is 
running if the processor is executing instructions 
on 
its behalf. It is considered ready if it is either running 
or able to run. A task is waiting if it has requested 
a message 
but has not received it. Finally, 
a task 


is suspended 
if some other 
task 
has specifically 
requested 
that 
it not be permitted 
to run. 
Each 
task has a permanent 
priority, 
which in- 
dicates its importance 
relative 
to other tasks in the 


system and to interrupts 
from peripherals. 
Priorities 


range from 0 to 255, with 0 being the highest priority. 
The "idle task" executes at priority 255 and prevents 
any other task at that priority 
from running. 
The 
ready task with the highest 
priority 
is the running 


task. 
The software 
priorities 
correspond 
to eight 
hardware 
interrupts 
(Fig. 2). When the running task 
has a high priority, 
interrupt 
levels associated 
with 


equal or lesser priorities 
are masked 
off. 


Interrupts provide real-time access 


An interrupt 
invokes an interrupt-service 
routine, 
which either requests 
an end of interrupt 
(using the 


Hardware 
Software 


Level 0 
Highest 


1 
priority 


Level 0 


16 
17 
1 


32 
33 
2 


48 
49 


3 


64 
65 
4 


80 
81 


5 


96 
97 
6 


112 
113 
7 


128 
129 


Lowest 
255 
priority 


2. Of 256 Interrupt 
levels, 
the top 129 ere essoclated 
with 
hardware. 
The remainder 
can be •• signed to software 
tasks. 


RQENDI procedure) or requests that a message be sent 
(using 
the RQISND 
procedure) 
to an interrupt 
ex- 


change associated 
with the active interrupt's 
level 


(Fig. 2). In the latter case, an interrupt 
task waiting 


at the interrupt 
exchange would complete the inter- 


rupt servicing. The system can enable interrupts 
(via 


the RQELVL procedure) 
and disable 
them 
(via the 


RQDLVL procedure) 
and can set the interrupt 
vector 


associated 
with 
a given priority 
level (using 
the 


RQSETV procedure). 


The iRMX 88 treats interrupts 
as messages. When 


an interrupt 
occurs, the Executive 
creates a special 


message and sends it to the exchange associated with 
that 
particular 
interrupt. 
Should a previous 
inter- 
rupt message be at the exchange when the interrupt 
occurs, the message is changed to indicate a missed 
interrupt. 
Any task awaiting the interrupt 
exchange 


receives 
the interrupt 
message 
and is readied 
for 
execution. 
If the task has a priority 
corresponding 


to the interrupt 
level, it will become the running task. 


The 
task 
that 
was 
running 
when 
the 
interrupt 


occurred 
is still ready 
to run, but is pre-empted. 


When the running task relinquishes 
control by wait- 


ing at an exchange (possibly for another 
interrupt), 
suspending 
itself 
(via the 
RQSUSP 
procedure), 
or 


deleting 
itself 
(via 
the 
RQDTSK 
procedure), 
the 


iRMX 88 dispatches 
the next ready 
task. 


Interrupt-processing 
tasks are simply tasks that 
wait at interrupt 
exchanges. They do not need to save 


the interrupted 
task's state or control the interrupt 


hardware. 
A task 
may simulate 
an interrupt 
by 
sending a message to an interrupt 
exchange (using 


the RQSEND procedure). 


Because 
the 
iRMX 88 imposes 
some 
software 
overhead, a direct interrupt-servicing 
facility is pro- 
vided for those cases where interrupt 
response time 


is critical. The interrupt 
vector is set with a pointer 


to an interrupt-service 
routine 
(using 
the RQSETV 


procedure); then all interrupts 
occurring at that level 
are handled by the interrupt-service 
routine, which 


is also responsible for all interrupt-logic 
control and 
state-saving. 
To complete the interrupt, 
the routine 


must 
use the RQISND or RQENDI procedure. 


Creating tasks and exchanges 


The iRMX 88' supports 
the dynamic 
creation 
of 


tasks and exchanges, as well as their deletion when 
they are no longer needed. Creating a task (with the 
RQCTSK 
procedure) 
places 
the 
new 
task 
on 
the 


system's list of ready tasks, according to its priority. 
The creation 
of an exchange 
(using 
the 
RQCXCH 
procedure) results in the initialization 
of an "empty" 
exchange-one 
that 
has 
no waiting 
messages 
or 


tasks. 
The deletion of a task (via the RQDTSK pro- 
cedure) results 
in its removal from all system lists. 


The 
deletion 
of an exchange 
(using 
the 
RQDXCH 


procedure) 
is only possible if no messages or tasks 


are waiting 
at the exchange. 


Suspension of a task (using the RQSUSP procedure) 


places 
the task 
on a list of suspended 
tasks 
and 


removes 
it from the list of ready tasks; to return 


the task to the ready state. 
the RQRESM procedure 


must 
be used. 


A coprocessor for number crunching 


Unlike previous operating 
systems. 
the iRMX-88 


can support the 8087 numeric-data 
processor (NDP) 
in a way that is invisible to the user. When an NDP 
task is created. the iRMX 88 initializes and maintains 
the state 
of the 8087 in a save area. 
Should 
an 


3. Int.ractlon 
b.tw •• n the t.rmlnaland 
a u•• r teak Involv •• 
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88 .xchang •• (gray). Some •• rv. for Input. from 


the k.yboard 
(top); oth •••• for output. 
to the CRT (boUom). 
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n•• d. a block of RAM, .xchangeRoFsAx 
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the r.que.lto 
the fre.-.pace 
manag.r, 
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an acknowledgment 
via RESP$EX. 
The ROFSRXexchange .erve. 


to relea •• the block. 


DESTINATION 
: 


1. 0000 
METERS 
4.0000 
METERS 
S.OOOO 
METERS 


MAXIMUM 
VELOCITY: 


0.0100 
METERS/SECOND 
0.1000 
METERS/SECOND 
0.0500 
METERS/SECOND 


POSITIONs 


X-I 
.•2000 
l1ZTERS 


Y 
• 
3.4000 
ME"I'BRS 


Z • 
2.1000 
METERS 
VELOCI'I"ts 
ox 
--0.0050 
METERS/SECOllD 


OY 
- 
0.0800 
METERS/SECOllD 


DZ 
• 
0.0500 
METERS/SECOND 


5. Th. arm of an Indu.trlal 
robot can mov.ln 
thr •• dlr.ctlon.: 


X, Y, and Z. Th. con.ol. 
dl.play 
r.port. 
current po.ltlon 
and 


velocity (left), 88 wella. 
thellmltlng 
value. 
(right). 


unmasked 
error 
occur in the 8087. an interrupt 
is 


generated 
on a configurable 
level. Using the default 


interrupt-service 
routine. 
the 
iRMX 88 sends 
an 


interrupt 
message 
to the interrupt 
exchange; 
the 


user can then supply his own error handler. The error 
task must specify itself as a non-NDP task or the 
system will deadlock. But the error interrupt. 
if used. 


must not be masked off. 


The Executive 
includes a terminal 
handler which 


establishes 
real-time 
asynchronous 
serial 
com- 


munication 
between an operator's 
terminal 
and the 


tasks 
running 
under 
the 
executive 
(Fig. 
3). The 


terminal 
handler 
provides 
a simple 
operator 
in- 


terface. 
which includes 
line-editing 
features, 
a 64- 


byte type-ahead 
buffer. and control over the output. 


Since all port addresses 
and interrupt 
levels for 


the terminal 
handler 
are configurable. 
it supports 


any 
component 
configuration 
using 
an 
8251A 


programmable-communications 
interface 
with 
an 


8253 programmable-interval 
timer 
for 
baud-rate 


generation. 
A task 
interfaces 
with 
the 
terminal 


handler through two exchanges. where messages are 
sent to initiate 
read and write requests; 
they are 


processed on a FIFO basis. Characters 
are read and 


written 
in response 
to interrupts 
from 
the 8251 


programmable-communications 
interface. 
Each re- 


quest results 
in the transmission 
of one line to or 


from the terminal. 
Read requests 
are sent to the 


RQINPX exchange, and write requests 
to the RQOUTX 


exchange. 
When 
a request 
has been serviced, 
its 
message is' sent to the specified response exchange. 
The iRMX 88 also contains 
a free-space 
manager, 
which maintains 
a pool of free RAM memory (Fig. 
4). Tasks request 
blocks of memory from the pool 


and return 
blocks to the pool. The request 
is made 
by sending 
a message 
to the manager's 
allocation 


exchange, 
RQFSAX, 
specifying 
the 
length 
of 
the 
needed block. If sufficient 
contiguous 
free RAM is 


available, 
the requesting 
task 
receives 
a message 


acknowledging 
the request 
and supplying 
the ad- 


dress of the block in the form of a message. Other- 
wise, the requesting 
task receives a message indicat- 


ing how much 
free 
RAM can 
be allocated. 
The 
requesting 
task may then ask for a smaller 
block. 
In either 
case, 
the response 
from 
the free-space 


manager 
is returned 
in the same message that was 


used for the request. If the task must have the block 
of memory, 
it makes an unconditional 
request; 
the 


Stitle 
('display 
algortlhlll') 
display: 
00; 
Sinclude(:f1: 
led. lit} 
'include( 
:f1 :rQisnd.e:4t) 
Sinclude( 
:fl :rqendi .ext) 
Sine lUde~ : f 1: rqwa 1t. ext) 
Sine 1uoe( :f 1:rQsetv .ext) 
Sinclude( 
:fl :,.qelvl.ext) 


O£ClAAE dlsolaySied 
1ntSexcnangddescr1otor 
Pllauc; 


/* display 
interrupt 
service 
routine 
*/ 
d\splaySisr: 
PROCEOIJREINTERAIJPT 
63; 


1* check 
for 
proper 
interrupt'" 
I 


OUTPUT( ro$8259.)-00h; 
IF 
NOT «(INPUT(ro$8159.) 
AND lJOh) 
- 
0) 
THEN 


00; 
1* 
outout 
next 
character 
""1 


OUTPUT( rQSthS8251) 
" outouUbuffer( 
outputS 
index) 
; 


outoutSindex 
" outoutSlndex 
+ 1; 


outputScount 
.. outputScount 
- 
1; 
IF outoutScount 
z 0 THEN 
CALLrqSisnd{ .dlsplaySexchange); 
ELSE 
CALL rQSendi 
( . di sp 1aySexchange) 
; 


END displaySisr; 


di'iplay: 
PROCEOIJRf; 
DECLARE messageSaddress 
ADDRESS; 


CAll 
rQSsetv( 
.d1sp 
layS 
i sr .d1 SP layS 
leve 
1). 
00 FOREVER; 


/* 
coPy 
monitor 
and 
control 
information 
into 
the 
display 
buffer 
with 
the 
ternplate 
of 
the 
display 
*/ 


outputS index 
~ I. 
outputScount 
" lENGTH( outputSbuffer); 


/* 
enable 
the 
display 
interrupt 
and 
wait 
unti 
1 
the 


buffer 
has 
been 
output 
*/ 
CALL rqSelvl(.disDlaySied); 
messageSaddress 
" rqSwa it{ 
.di'iP 
layS 
ied.O); 
END 
d; SP lay; 


6. The PROCEOURE 
DISPLAv(boltomhell) lIIustretes how the 
IRMX 88 operating system deals with random events. Here, 
Interrupt level 63 has been chosen by the user. 


free-space 
manager 
then 
lets the requesting 
task 


wait until sufficient 
memory 
is available. 
When a 


block of RAM is no longer needed, it may be sent 
to the reclamation 
exchange 
(RQFSRX) 
where 
it is 


merged 
into the free-space 
pool. 


The building-block approach 


The iRMX 88 Executive is completely configurable. 


The minimum 
"nucleus" 
consists 
of the following 


procedures: 
RQSTRT 
(initialization), 
RQCfSK 
(task- 


creation), 
RQCXCH (exchange-creation), 
RQSEND, 
and 


RQWAIT. 
Any of the remaining 
procedures 
are auto- 


matically 
included when they are referenced. 
Inter- 


rupt 
support 
and the system 
clock are separately 


configurable. 
The port addresses 
used for the 8259A 


programmable-interrupt 
controller, 
the 8251A pro- 


grammable-eommunications 
interface, 
and the as- 


sociated 8253 programmable-interval 
timer are con- 


figurable 
to any iAPX 86 or iAPX 88 port address. 


The transmission 
rate 
of the terminal 
handler 
is 


configurable 
from 150 to 19,200 baud. The interrupt 


levels for the 
system-elock 
and 
terminal-handler 


interrupts 
are configurable 
to any level of the 8259A 


programmable-interrupt 
controller. 
Any 
unused 


level is configured 
to its default 
interrupt-service 


routines. 
The base of the interrupt 
vector used by 


the 8259A programmable-interrupt 
controller can be 
selected from interrupt 
levels 8 to 248. The smallest 
system 
time unit is 1 ms. 


An "interactive 
configuration 
utility" 
(lCU 88) 


simplifies 
the configuration 
process. 
This 
utility, 


which executes 
on the Intellec 
microcomputer-de- 
velopment 
system, 
asks the user a series of ques- 


tions, allowing him to specify his own board con- 
figuration 
or to use a default that corresponds 
to the 


iSBC 86/12A, iSBC 86/05, or iSBC 88/40 boards. 


To transfer 
an application 
from the iRMX 80 to 


the iRMX 88 Executive, 
the user must change the 


parameter 
for the create-task 
(RQCfSK) 
procedure 


from a 16-bit address to a 32-bit pointer. The descrip- 
tion of the task can then be placed in random-access 
or read-only memory. In the iRMX 88, the definition 
of task has been expanded to incorporate 
a flag that 


indicates 
whether 
or not 
the 
8087 numeric-data 


processor will be used. If that flag is set, an additional 
94 bytes must be reserved for the task. Furthermore, 
the first parameter 
of the set-vector 
(RQSETV) 
pro- 


cedure 
must 
be changed 
to a 32-bit pointer. 


A robot demonstrates 
Implementation 


The iRMX 88 Executive demonstrates 
its value in 
a typical application: controlling an industrial 
robot's 


arm. 
The 
position 
of the 
arm 
in each 
of three 


dimensions 
is measured 
by an analog 
voltage 
on 


three input lines. The speed and direction 
of move- 


ment in each dimension is controlled with an analog 


00 
FOREVER; 


DO CASE fleld 
+ 1; 


/* next 
J( position 
*/ 


00; 
1* convert 
the 
character 
string 
in 
the 
input 
buffer 
into 
a real 
number */ 


7. An endless 
loop Is atypical 
method lor capturing 
Input. 
The skeleton 
code lor PROCEDURE 
INPUTshowsthe Interlace 
with 
the executive 
via a CALLto an as procedure. 


Stitle 
('monitor 
algort1hm') 
monitor: 
00;.... 
1* FIlOf'litor 
)( task 
*/ 
ronitor$x: 
PROCEOURE; 
D£ClARE messagehddress 
ADDRESS; 
CALL rq$cxcn( 
.waiting$ed); 


00 
FOREVER· 
'*IIt,•• rtf4\ilMlllP 


messageS address 
•• rq$acpt( 
.wait ;ogSed); 


dcontrolS1nput 
•• SHR( INPUT(aacSlow). 
4) 
+ 


SHL( INPUT(adc$high), 
4); 
xSmonitorSposit1on" 
dcontro1$1nput 
* d1nDut$scale; 


xSrate" 
( dpos1tlon 
~ dmonitorSpesit1on 
) * lQi 


doosition 
•. -xsmonltorSoositi6n; 
--- 
--_ 
..~ ._- 
-- 


CALLrq$send{. 
xSact tonSed, 
. dpos it ionSmessage); 


ENO; 
[NO mon1tor$x; 


8. 
PROCEOURE 
MONITORSXlsa task that hasto run every 16 ms. 
The IRMX 88 procedure 
RQWAITacceptsthe desired 
time delay 


as an argument. 


Stitle 
('control 
algorithm') 
control: 
00; 
1* contro 
1 x task 
*1 
controlh: 
PROCEDURE; 
DECLAREmeo.;o.;agehddreso.; ADDRESS; 


00 
FOREVER; 
messageSaddress 
" rQ$wait( .dactionSed,O); 


dcontrol1current 
:c maddrate 
.•. 


( nextSdpos1tion 
- dposH1on 
) I ABS( nexthSposit1on 
- 
lao.;thSposH1on 
); 
dcontrolSoutput 
a SHl{ FIX ( 
dcontrol1current 
.•. dscale 
). 
4) • doutputSselect; 


OUTPUT(dacSh1gh) ,. HIGH(xScontrolSoutDut}; 
OUTPUT(dacSlow) " LOW(dcontrolSoutpul); 


END; 
ENDcontrolh; 


9. This control 
algorithm 
sends data to the robot arm's x- 


axis through 
a d-a converter. 
The task remains 
dormant 
until 


the INPUTprocedure 
Irom Fig. 7 makes It up. 


current 
on three output 
lines. 


The hardware 
consists of an iSBC 88/40 board with 


an iSBC 337 high-speed math multimodule, 
an iSBX 


328 analog-output 
multimodule, 
and a CRT terminal 


with an RS-232 serial interface. 
The position of the 


arm in any dimension is read from the a-d converter 
on the iSBC 88/40; the converter 
is multiplexed 
over 


the three analog inputs. 
The d-a converter 
on the 


iSBX 328 analog-output 
multimodule 
is multiplexed 


to control the current to three stepper motors, which 
in turn control the arm's motion. A display (Fig. 5) 
is maintained 
on the CRT terminal 
and gives the 


robot's current position in three dimensions, 
the rate 


of change in each direction, and updatable 
fields for 


the desired position, as well as the maximum 
rate 


of change in each direction. 
The display 
algorithm 
(Fig. 6) continuously 
up- 


dates the display from the control and monitor data 
bases. The monitor 
and control data bases update 


the display 
buffer. 
The display 
task initializes 
the 


display index and display count, enables the display 
interrupt, 
and 
waits 
at the display-interrupt 
ex- 
change. 
The display-interrupt 
service 
routine 
re- 


sponds to display interrupts 
by outputting 
the next 
character 
from the display 
buffer. 
When the last 
character 
in the display 
buffer 
has been output, 
a 


message is sent to the interrupt 
exchange; otherwise 


an end-of-interrupt 
is sent. 


The input algorithm 
(Fig. 7) accepts digits as they 


are typed on the CRT terminal 
and enters them into 


the control 
field being updated. 
The fields on the 


right-hand 
side of the display are updated, 
starting 
with the top field and progressing 
to the bottom. 


Entry 
of a carriage 
return 
causes the values in the 


updated 
field to update 
the control-data 
base; the 


input 
algorithm 
then 
proceeds 
to the next field. 


Backspace 
discards 
the last digit typed. All other 


characters 
are ignored, 
and the user cannot 
type 


outside the defined fields. The input-interrupt 
rou- 


tine receives a character 
with each interrupt 
and 


copies it into the display 
and input 
buffers. 


The monitor algorithm 
(Fig. 8) samples the posi- 


tion of the robot's arm 60 times per second. It updates 
the monitor data base and then signals the control 
program 
through 
the appropriate 
exchange. 


The control algorithm 
(Fig. 9) waits at the proper 


exchanges 
for a message 
from 
the 
input 
or the 


monitor algorithms. 
It then outputs a control current 


to the d-a converter 
based on the relative 
position 


of the robot's 
arm.O 
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I. INTRODUCTION 


The introduction 
of the single board 
computer 
as a 
tool for the system designer 
has opened 
the way for 


many 
varied 
application 
areas 
to benefit 
from 
the 
advantages 
of computer 
utilization. 
A problem 
still 


exists, 
however, 
because 
the 
available 
I/O 
con- 
figurations 
have been largely incompatible 
with the 
wiring and packaging 
techniquet; 
required 
in indus- 
trial 
environments. 
This 
problem 
is overcome 
by 
the utilization 
of the Intel® iCS™ product 
family. 
The purpose 
of this application 
note is to provide 
a 


representative 
approach 
to the implementation 
of a 
computerized 
solution 
to 
an 
industrial 
control 


system. 


System Description 


This 
application 
note 
will 
deal 
with 
a 
control 


system which will regulate 
the temperature 
in each 


of four ovens. 
Each 
oven will be defined 
as utiliz- 


ing a light bulb for heating. 
Normal 
convection 
will 


be used to provide 
cooling. 
The internal 
tempera- 


ture will be measured 
by means 
of a thermistor 
in- 
stalled in each oven. We will assume 
that we will be 
required 
to implement 
some type of operator 
panel 


near the ovens which will allow 
the status 
of each 


oven to be monitored. 
This approach 
is similar 
to 


many 
common 
industrial 
applications 
which 
re- 


quire a supervisory 
control 
station 
in one area and 


a 
separate 
operator 
interaction 
panel 
near 
the 


equipment 
being 
controlled. 
The setpoint 
and tol- 


erances 
should 
be input 
from an external 
location. 


With these facts about 
our system defined, 
we can 


begin 
a step by step solution 
to providing 
a com- 


puterized 
control 
system to operate 
the ovens. 
We 


will discuss 
the various 
equipment 
trade-offs 
and 


the decisions 
which will be used to define 
the hard- 


ware/software 
designs. 


Control 
Algorithm 


Before 
we can begin the design 
of our system, 
we 
must have a clear idea of the technique 
we will use 


to control 
the 
system. 
Our 
control 
system 
must 
maintain 
the oven temperature 
within 
a predefined 
and 
fairly 
narrow 
range 
of 
the 
set point. 
Let 
us 
make an assumption 
that the light bulb will be con- 


trolled 
digitally, 
meaning 
that the bulb must either 


be turned 
fully on or it must 
be turned 
fully off. 


The obvious 
control 
technique 
then becomes 
turn- 


ing the bulb on when the temperature 
of the oven is 


below 
our 
lower 
limit 
and 
turning 
the 
bulb 
off 
when 
the temperature 
is above 
the higher 
limit. 
It 
seems reasonable 
to assume 
that this technique 
will 


provide 
a temperature 
in the 
oven 
which 
varies 
sinusoidally 
with 
time. 
This 
is true 
because 
even 


though 
the lamp 
is turned 
off, 
it will continue 
to 
generate 
heat for a short 
period 
of time. 
Likewise, 
when the bulb is turned 
on, it will not instantly 
be 
able to provide 
h(at to raise the temperature 
of the 


chamber. 
We would 
expect 
to have 
a system 
re- 


sponse 
such 
as 
is shown 
in Figure 
I. 
A 
better 


method 
of control 
can 
be devised 
if we provide 


some type of temperature 
prediction 
into our con- 


trol 
algorithm. 
Since 
this 
utilizes 
the 
rate 
of 


temperature 
increase 
or decrease, 
it will involve 
a 
type of derivative 
control 
system. 
This 
derivative 


control 
action 
will tend to dampen 
the temperature 


oscillations 
which might be encountered 
if only an 
instantaneous 
on-off 
control 
system 
were utilized. 


Figure 
2 shows 
the 
response 
with 
time 
that 
we 
might 
expect 
with this type of control 
system. 


The 
second 
approach 
is 
superior 
to 
the 
first 
because 
the control 
will provide 
a much 
smaller 
oscillation 
of the 
oven 
temperature. 
Other 
solu- 


tions 
are possible, 
such as providing 
a modulated 
output 
to the lamp. 
However, 
in an attempt 
to pro- 
vide 
a simple 
model 
upon 
which 
to expand 
our 
system solution, 
we will assume 
that the second 
ap- 
proach 
will provide 
us with 
an accurate 
enough 
control 
of the oven temperature. 


Having 
made 
the decision 
as to the control 
tech- 


nique, 
we can proceed 
with the task of determining 


the general 
system 
configuration. 
That 
is, we can 


define 
the physical 
system 
characteristics 
and 
the 


components 
to which 
we must 
interface 
the com- 
puter 
system. 
This 
approach 
is identical 
to 
that 


which 
would 
be used 
in a conventional 
control 
system 
design. 


Basic System Configuration 


Based 
upon 
the data 
which 
we have 
provided 
so 


far, 
it is possible 
to build 
a block 
diagram 
of the 
system's 
major 
components. 
The 
system 
consists 


of four 
ovens, 
an operator's 
panel, 
a data 
entry 


panel, 
and 
the actual 
control 
logic. 
A block 
dia- 
gram 
for the system is shown 
in Figure 
3. We must 
now 
further 
define 
the elements 
which 
make 
up 
each of these blocks. 


Each oven must consist of a heating 
element, 
which 
we have already 
defined 
as being a light bulb, and a 


temperature 
sensing 
element 
which 
we have 
said 


will be a thermistor. 
Each 
heating 
element 
will be 
switched 
on 
or 
off 
by applying 
or 
removing 
a 


source 
of 
115 VAC. 
The 
thermistor 
temperature 


can be sensed 
by using the thermistor 
in a voltage 


divider circuit. We can then measure the voltage 
across a fixed -resistor to obtain an analog signal 
which is proportional 
to the oven temperature. We 


will determine 
the required 
value of the fixed 


resistor at a later time. 


The operator's panel should be designed to provide 
the work floor operator with basic information 
as 


to the status of each oven. It should also allow 
some method by which he can inhibit the operation 
of any oven should it become necessary for charg- 
ing or servicing the oven. We can then define the 
basic elements which should make up the opera- 
tor's control panel. Each oven should have associ- 
ated with it the following controls and indicators: 


I. Oven ON/OFF Switch - 
This switch will allow 


the operator 
to inhibit the oven operation 
by 


turning the appropriate 
oven switch to OFF. 


2. Oven RUNNING 
Indicator 
- 
This indicator 


will provide a visual indication that the oven is 
activated and that the temperature is being con- 
trolled. 


3. Oven IN TOLERANCE 
Indicator - 
This indi- 


cator will turn on when the oven temperature 
falls within the allowable bandwidth around the 
setpoint for that oven. 


4. Oven ALARM Indicator - 
This indicator is the 


complement of the in tolerance lamp. It will be 
turned on when the oven is activated and the 
temperature 
does not 
lie within the desired 


bandwidth. 


5. Oven CAUTION Indicator - 
It may be neces- 


sary to alert the operator 
to a potential oven 


temperature control problem before it actually 
occurs and sets off the alarm indicator. Since we 
have defined our control algorithm as utilizing a 
type of derivative control, 
we can project the 


oven temperature 
ahead in time. We will turn 


the oven caution indicator on when we predict 
that the oven temperature will lie outside of the 
desired bandwidth 
in a predetermined 
future 


time period. 


We have now defined the operator interface which 
we will utilize to control and monitor 
the oven 
processes. 


At this point, we will make a decision that the in- 
terface used to input the setpoints will utilize a 
CRT terminal. Though the decision may seem to be 
completely arbitrary, we will see later that CRT ter- 
minals 
provide 
an extremely 
useful 
device for 
allowing an operator to communicate with the sys- 
tem. Once the decision has been made, we have no 


further requirements to consider hardware design 
for this terminal, as the entire operation 
can be 
handled in the software developmen~ which will l;le 
considered later. 


A common technique for documenting a system is 
the ladder diagram. At this time, we can construct 
a ladder for our control system. Unlike conven- 
tional design techniques, our ladder diagram need 
only be concerned with the actual drive and sensing 
circuits since the logic required to drive the various 
outputs will be defined using software. This results 
in a considerable simplification of the design pro- 
ces.s.A ladder diagram for a typical oven is shown 
in Figure 4. We can defer the implementation 
of 
the control algorithm until we begin to develop the 
software portion of our control system. It is now 
possible to complete the external hardware design 
and to implement the system wiring package. 
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II. 
WIRING 
INTERFACES 


A major pitfall in utilizing a computer for control 
systems has traditionally been the requirement for 
the 
design 
engineer 
to expend 
a considerable 


amount of his time in designing interfaces to con- 
nect the physical wiring to the computer system. 
The introduction of Intel's product line of termina- 
tion panels has essentially eliminated the require- 


ment of designing 
interfaces 
and allows more engi- 


neering 
time to be spent providing 
a solution 
to the 


application. 
Before 
we continue 
with 
the specific 
design, 
we should 
spend 
some 
time discussing 
the 
various 
types 
of termination 
panels 
available 
and 


the general 
characteristics 
of each panel. 


Analog 
Termination 
Panels 


The 
Intel® iCS 91O'M Analog 
Termination 
Panel 


has been designed 
to provide 
a simple means of ter- 
minating 
the 
analog 
wiring 
and 
of providing 
an 


interface 
to the control 
system 
input/output. 
All 


wiring 
is terminated 
utilizing 
pressure 
type screw 
barrier 
blocks. 
Termination 
blocks 
have been pro- 


vided 
to allow 
the termination 
of up to 32 single- 


ended 
or 16 differential 
channels 
of analog 
input. 


For use in a differential 
input environment, 
such as 
we will be using, the terminator 
blocks provide 
wir- 


ing terminations 
compatible 
with shielded 
cable in- 


puts in that provision 
has been made 
to accept 
the 


shield 
of each input 
signal. 
The shield 
is then car- 


ried through 
the on-board 
circuits 
to the analog-to- 
digital 
converter. 
Provision 
has been made 
on the 
board 
for the mounting 
of commonly 
used circuits 
for signal conditioning. 
The available 
signal condi- 


tioning 
circuits 
provide 
for installation 
of current 


termination 
resistors 
and the installation 
of a single 


pole 
low 
pass 
filter 
network. 
The 
basic 
barrier 


assignments 
for the iCS 910 termination 
panel 
are 


shown 
in Figure 
5. The possible 
circuit 
networks 


for this panel 
are illustrated 
in Figure 
6. A com- 


plete 
description 
of the analog 
termination 
panel 
can be found 
in the iCS 910 Analog Signal Condi- 


tioning/Termination 
Panel Hardware 
Reference 


Manual (manual 
order 
number 
9800800A). 


The functions 
of the analog 
termination 
panel will 


become 
more clear as we develop 
the actual 
config- 


uration 
required 
to support 
our oven application. 


Referring 
to the ladder 
diagram 
(Figure 
4) we see 


that a fixed resistor 
is necessary 
to provide 
the volt- 


age divider 
network 
to sense the oven temperature. 


The 
current 
termination 
resistor 
(Rc) 
on 
the 


iCS 910 board 
can be used to provide 
a convenient 


mounting 
location 
for 
this 
component 
(refer 
to 


iCS 910 circuit 
schematic, 
Figure 
6). At this point, 


we must 
make a design decision 
regarding 
the uti- 
lization 
of a low pass filter for our analog 
circuits. 


Since the oven temperatures 
are not expected 
to ex- 


hibit rapid 
fluctuations 
with time, the use of a low 


pass filter will not adversely 
effect 
the temperature 
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sensing. 
Indeed, 
the use of a low pass filter should 


contribute 
to spurious 
signal 
rejection 
should 
the 


analog 
cables pick up external 
noise signals. 
Calcu- 


lations 
will show 
that 
the use of a filter 
network 


consisting 
of 11K ohm series resistors 
and a 2.2 ILF 


capacitor 
will 
provide 
the 
filter 
characteristics 


shown 
in Figure 
7. 
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Based upon 
our requirements 
and using the circuit 


schematic 
of Figure 
6, we can provide 
the circuit 


interfaces 
required 
by our ladder 
diagram 
(Figure 


4) by configuring 
the channels 
of the iCS 910 ter- 


minator 
as shown 
in Figure 8. This results in a sim- 


ple two-wire 
per oven analog 
interface. 
The termi- 


nator 
board 
is designed 
to connect 
to the various 


analog 
I/O 
boards 
by means 
of a standard 
ribbon 


cable which 
is supplied 
with the terminator 
panel. 


The 
actual 
selection 
of 
the 
appropriate 
analog 


board 
will be deferred 
until 
later. 
We will define 


that oven number 
1 will correspond 
to the differen- 


tial analog 
channel 
0; oven 2 will correspond 
with 


channel 
I; oven 3 will correspond 
with channel 
2; 


and oven 4 will use channel 
3. This leaves 12 analog 


differential 
channels 
available 
for 
future 
expan- 


sion. The channel 
selection 
just made was a purely 


arbitrary 
choice. 


The 
wiring 
to the 
iCS 910 terminator 
panel 
can 


then 
be made 
essentially 
as shown 
in Figure 
9. 


Clearly, 
the 
use of 
the 
tt:rminator 
panel 
greatly 


simplified 
the connection 
between 
the control 
sys- 
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tem and the physical 
devices which are to be moni- 


tored 
or controlled. 
Figure 
10 shows 'the placement 


of the components 
onto 
the board. 


Low Voltage 
Digital 
Termination 
Panels' 


Looking 
again 
at our ladder 
diagram 
for an oven 


control 
system 
(Figure 
4), we see th'e need to pro- 


vide a second 
type 
of interface 
signal. 
This 
is to 


provide 
the 
switching 
for 
the 
various 
indicator 


lamps 
used on the operator's 
control 
panel. 
Tradi- 


tionally, 
this interface 
has been 
handled 
by using 


electromechanical 
relays. The coils would be driven 


by the 
low voltage 
controi 
system 
and 
the relay 
contacts 
were used to drive the external 
indicator~. 
Modern 
technology 
provides 
us with a solid state 


device 
to perform 
the same 
fll11ctiori, 'the 
optical 


isolator. 
We 
can 
use these 
devices 
to provide 
a 


highly reliably 
and low cost alternative 
to the relay 
interface. 
The Intel® iCS 920'" 
Digital Signal Con- 


ditioning/Terminator 
Panel 
provides 
us 
with 
a 


convenient 
vehicle 
for 
mounting 
the 
optical 


isolator 
circuits 
and 
for 
terminating 
the 
wiring 


associated 
with the indicator 
devices. 


The iCS 920 panel 
is designed 
to be used by those 


interface 
circuits 
which incorporate 
operating 
volt- 


ages less than 50 volts and whid) 
generally 
use cur- 


rents which 
are smaller 
than 300 mA. These limits 


are given only for a general 
guideline 
since a wide 


variety of optical 
isolators 
and drivers are available 
for 
use 
on 
the 
board. 
Some 
of 
the 
devices 
are 


capable 
of handling 
greater 
voltages 
or currents. 
A 


representative 
list of available 
devices 
and 
com- 


plete details 
of-the 
termination 
panel 
are available 


in the iCS 920 Digital Signal Conditioning/Termi- 
nation Panel Hardware Reference Manual (manual 
order 
number 
980080IA). 


The 
c\,igital panel 
provides 
terminations 
for up to 


24 digital 
channels, 
each: of 
which 
can 
be con- 


figured 
as either an input 
or an output 
channel 
ac- 


cording 
to the 
sp~cific 
application. 
requirements. 


As with the analog 
termination 
panel, 
all wire ter- 


minations 
are 
made 
using 
pressure 
type 
barrier 


strips which will accept 
up to 16 gauge wire. The 24 


digital 
channels 
correspond 
with those 
input/out- 


put 
channels 
assigned 
to the 
standard 
Intel 
I/O 


configurations 
used on the single board 
computers 
and 
I/O expansion 
boards. 
We will dwell more on 


this 
subject 
later 
when 
we define 
the 
addresses 


associated 
with each 'circuit which 
we desire 
to in- 


corporate 
into the termination 
panel. 


Since 
the digital 
channels 
can 
be configured 
into 


either an input 
or an output 
mode, 
it is wise to dis- 


cuss each configuration 
so that a clear understand- 


ing of the board 
can be obtained, 
even though 
our 


application 
example 
will only use the output 
mode 
with this board. 


Figure 
II provides 
a schematic 
of the panel when it 


is configured 
for a digital 
input 
mode. 
To set up a 


channel 
to operate 
as an input, 
it is necessary 
to 


add at least 
two jumpers 
to the wire-wrap 
jumper 


posts. 
As can be'seen, 
pins 6 and 4 must 
be con- 


nected 
together 
as well as pins 3 and 5. If the board 


is to prpvide 
a visual LED indication 
of the channel 
status, 
an additional 
jumper 
should 
be installed 


bet~een 
pins I and 2 of the jumper 
posts. 
If this is 


done, 
be certain 
to take into account 
the additional 
cur~ent requirements 
when calculating 
the required 


input 
resistors. 
Two 
resistor 
mounting 
locations 


are provided 
to allow installation 
of selected 
com- 


ponents 
to 
handle 
the 
current 
limit 
through 
the 


optical 
isolator 
(Rx) and the threshold 
voltage 
for 


turn-on 
of the device 
(Ry). 
A complete 
and 
de- 


tailed 
procedure 
for selecting 
these resistors 
based 


upon 
the input 
voltages 
is pro~ided 
in the iCS 920 


hardware 
reference 
manual 
mentioned 
earlier. 
Pro- 
vision has also been made on the termination 
panel 


for 
the 
installation 
of 
a diode 
(CR) 
to 
protect 


against 
reverse 
bias application: 


The components 
have been placed on the board 
ar- 


~anged 
in groups 
of two channels. 
This 
eases 
the 


task of finding 
various 
components 
or of locating 


the holes 
for installing 
the required 
components. 


This layout 
is illustrated 
in Figure 
12. It is impor- 


tant 
to take note of the physical 
placement 
of the 


optical 
isolator 
chips in the 20-pin socket. 
This in- 


stallation 
location 
must - be 
followed 
rigorously 
when using a channel 
in an input 
mode. 
Also take 


note that provisions 
are provided 
for mounting 
two 


sizes of resistors 
in location 
(Rx). This will' accom- 


mod ate the power 
dissipation 
requirements 
which 
will be encountered 
in various 
application 
situa- 
tions. 
Referring 
again 
to Figure 
12, note 
that 
the 
upper 
half 
of the layout 
represents 
odd 
channels 
and the lower portion 
of the layout is used for even 


channel 
component 
mounting. 
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Figure 11. iCS 920™ Digital Terminator Input 
Configuration 


When 
the iCS 920 panel is used in this input 
mode, 


it corresponds 
to the utilization 
of a relay coil to 


sense some external 
contact 
closure. 
The resistors 


can be thought 
of as selecting 
the coil's 
operating 


voltage 
and 
the diode 
provides 
the same 
transient 


protection 
function 
as when installed 
on an electro- 
mechanical 
relay. 
Finally, 
the optical 
isolator 
out- 
put corresponds 
to the contacts 
associated 
with the 


relay coil. As we will see later, 
this approach 
pro- 
vides us with an unlimited 
number 
of contacts 
per 
relay coil. 


The oven application 
requires 
a contact 
for driving 


the indicator 
lamps 
associated 
with each 
oven. 
If 


we define 
the driving 
voltage 
to be 24 volts DC, we 


will find that the voltage 
and current 
requirements 


fall within 
the limits specified 
for using the iCS 920 


Digital 
Signal 
Conditioning/Termination 
Panel. 


Let us examine 
in more detail 
how this can be ac- 
complished. 


We 
will 
select 
an 
industrial 
indicator 
assembly 


which 
utilizes 
a full voltage 
24-volt 
lamp. 
Typical 
lamps 
would 
be type 387. This will require 
a drive 


of 40 mA at 28 volts. Our switching 
device must be 


capable 
of 
driving 
this 
load. 
The 
analogy 
used 


earlier 
to compare 
the optical 
isolator 
with a relay 


in an input 
mode 
holds 
true 
when 
we utilize 
the 


devices 
in an output 
configuration. 
If we examine 


the data 
sheet for the current 
switching 
character- 
istics of a typical 
optical 
isolator, 
say the TIL 
113 


(Appendix 
A), we can see'that 
the current 
and volt- 
age 
requirements 
fall 
well 
within 
the 
allowable 


ratings 
of the device. 
We have 
selected 
the relay 


contact 
characteristics! 
We need not concern 
our- 
selves 
with 
the 
selection 
of 
current 
limitation 


resistors 
(coil voltage 
ratings) 
since this circuitry 
is 


provided 
on the terminator 
panel 
when a circuit 
is 
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configured in an output mode. If we refer to Figure 
13, we can see the on-board schematic for the out- 
put drive mode of operation. Two jumpers must be 
installed for each output 
channel. The first, be- 


tween pins 1 and 2, is used to enable the LED chan- 
nel status indicator. 
The second, between pins 3 


and 4, actually connects the computer generated 
drive signal to the input of the optical isolator 
(analogous to connecting the relay coil to the driv- 
ing line). Provision has been made on the circuit 
board for only one optional component in the out- 
put mode; this is the resistor (Rz). This component 
has the effect of increasing the response time of the 
switching device. Because our indicator lamps are 
not time critical, we will choose to omit the instal- 
lation of this component. 


Figure 14 provides a drawing showing the location 
of the components on the iCS 920 panel when it is 
utilized as an output switch. Again note the place- 


ment of the optical isolators in the 20-pin sockets. 
Also note the jumper arrangement used to provide 
the required output circuitry. 
Again referring to Figure 13, we see that an alter- 
native to using the optical isolator for a switch 
exists. Provision has been made on the panel for 
the installation of high power buffer/driver 
chips 


such as the TI 75462. This device provides the same 
coil! contact characteristics as our optical isolator; 
however, no isolation between the input and out- 
put is provided. In certain applications, 
this con- 


figuration 
may -be desirable 
and can be imple- 


mented by connecting jumpers 
1 and 3 together, 


then placing a jumper block in the isolator socket 
location. 
The oven application 
will not use this 


mode because of the many advantages which isola- 
tion can provide. 


Prior to actually installing the components 
onto 


the iCS 920 panel, it is ~ecessary to assign the 
lamps to definite channel addresses. This involves 
making some additional 
assumptions 
and design 


configuration 
deciSions. If we consider the total 


number of digital inputs and outputs which are re- 
quired to handle all four ovens (including the as yet 
unconsidered 
switch and heater signals), we see 


that a total of 24 channels will be required. These 
will be broken out as shown below: 


No. of 
Channels 


16 
4 
4 


Type 
DC 
AC 
AC 


Function 


Oven indicator lamps 
Oven heaters 
Oven RUN switches 


~ 
~ 
G---C::)---E) 8 


0 r- 0 
G-GD--B 
~ ~ ~0 
0 
0 
0 


~CJ'~N 
0 
0 
0 
0 
( 
? 
G-GD--B 
0 
0 0 


( 
~ 
0 
0 


~ 
8 


0 
D 0 
G---C::)---E) 
0 
0 
~~~o 


0 
0 
0 
0 
0 


~ 


We have indicated 
that the 16 indicator 
lamps can 


be handled 
using 
the iCS 920 panel. 
An examina- 


tion of the data 
sheets 
for the various 
Intel single 


board 
computers 
and expansion 
boards 
provides 
us 
with the fact that a common 
characteristic 
of most 


boards 
is the use of at least 
one 
Intel 
8255 Pro- 
grammable 
Peripheral' 
Interface. 
This 
provides 
us 


with 
at least 24 I/O 
lines with 
which 
to work 
on 


each single board 
computer. 
WI!: can then assume 


that we will not require 
an I/O expansion 
board 
to 


implement 
our application. 
Ideally, 
we can handle 


our total 
requirements 
with one parallel 
interface. 


The various 
Intel parallel 
ports 
are brought 
off of 


the 
computer 
and 
expansion 
boards 
using 
edge 


connectors. 
These 
edge 
connectors 
are 
then 
con- 


nected 
to the termination 
panels 
using 
a standrd 


ribbon 
cable assembly, 
effectively 
providing 
an ex- 


tension 
of 
the 
I/O 
ports 
out 
to the 
termination 


panels. 
The 24 channels 
are grouped 
into three I/O 


ports 
(each consisting 
of 8 channels 
pr bits) which 


are then called 
port A, port 
B, and port C. When 


connected 
to the iCS 920 panel, 
these 
ports 
and 


their bit assignments 
will be as shown 
in Figure 
15. 


At this point, 
we seem to be in a dilemma 
since we 
would 
like to use all 24 channels 
and we have used 


only 16 of them on our panel while we have utilized 
the edge connector 
of the interface. 
It would 
be 


desirable 
to 
have 
some 
technique 
to extend 
the 
other 
8 channels 
to 
a 
high 
voltage 
terminator 


panel. 
It might 
be well to interrupt 
our 
channel 


assignments 
at this time 
to jump 
ahead 
and 
con- 


sider the features 
of the iCS product 
line which will 


enable 
us to accomplish 
our interface 
desires. 
We 


will then consider 
the interface 
of the high voltage 
signals 
to our 
control 
system 
before 
returning 
to 


the 
problem 
of 
assigning 
port 
locations 
to 
our 


lines. 


High Voltage 
Digital Termination 
Panels 


The 
Intel® iCS 
930r" 
AC' Signal 
Conditioning/ 


Termination 
Panel is designed 
to interface 
up to 16 


AC signals (up to 280 volts at 3 amps) 
or high cur- 


rent 
DC signals 
(up to 50 volts at 3 amps) 
to the 


parallel 
ports 
of the Intel single 
board 
computers 


or I/O expansion 
modules. 
The barrier 
strip termi- 


nations 
on this panel are designed 
to easily handle 


the 14 gauge wire commonly 
found 
in applications 


requiring 
the use of the AC terminator. 


Solid state 
relays are used to provide 
the interface 


between 
the computer 
I/O 
ports 
and 
the physical 


plant devices. 
These devices make the utilization 
of 


the panel 
a simple 
task once a ladder 
diagram 
of 


the required 
circuits 
has been drawn. 
As we have 


previously 
mentioned 
and as is clear from 
looking 


at Figure 
4, we shall 
need 
to utilize 
eight 
of the 


available 
circuits, 
four for input 
and 
four for out- 


put. 
The 
implementation 
of each 
signal 
type 
re- 


quires 
only that 
we insert 
the correct 
type of solid 


state relay into the appropriate 
socket. 


First, 
consider 
the 
input 
configuration 
which 
is 


required 
to sense 
the position 
of the oven 
RUN 
switches. 
Figure 
16 shows 
the 
circuit 
schematic 
when 
used in the input 
mode. 
We can see that 
the 


output 
signal will turn on when the input 
power 
is 


applied. 
Like 
the digital 
termination 
panel, 
each 


circuit's 
status 
is indicated 
by means of an LED in- 


dicator 
installed 
on the board. 
The input 
circuit 
is 


protected 
by a socketed 
3-amp 
fuse which 
may be 


replaced 
without 
the need 
to solder 
any 
compo- 


nents. 
The solid state relay used for this configura- 


tion should 
be a type lACS which is available 
from 


either 
Opt9-22 
or Motorola. 
Complete 
details 
of 


available 
relays 
and 
their 
uses on 
the 
board 
are 


available 
in the iCS 930 AC Signal Conditioning/ 


~~~~--~ 
7654321076543210 


Termination 
Panel Hardware Reference Manual 


(mahual 
order 
number 
9800802A). 
Keep in mind 


the fact that 
although 
this application 
note repre- 


sents the solid state relays as being actual reiays and 
contacts, 
they in fact are solid state and contain 
no 


moving 
parts. 


The 
output 
configuration 
is utilized 
to turn 
the 


heater 
elements 
(the light bulbs) on and off. Figure 


17 provides 
us with a schematic 
of the output 
cir- 


cuitry. 
In this case, we will insert a solid state relay 


of type OAC5 
which 
will handle 
up to 140 volts 
RMS at 3 amps. 
In some cases, 
it might 
be desir- 


able to add 
certain 
components 
to the terminator 


panel when using it in the output 
mode. Two possi- 


ble 
circuit 
configurations 
are 
possible. 
The 
first 


and 
perhaps 
the most 
common 
will consist 
of in- 
stalling 
a MOY 
(metal 
oxide 
varistor) 
across 
the 


solid 
state 
relay 
contacts. 
This 
will be 
required 


when the load being driven 
is inductive 
in order 
to 


prevent 
the transients 
generated 
by the load 
from 


damaging 
the triac 
in the SSR (solid 
state 
relay). 


Since 
the SSRs 
utilize 
zero 
voltage 
switching 
and 


the load in our ovens is resistive 
rather 
than induc- 


tive, our application 
will not necessitate 
the instal- 


lation 
of this device. The second 
possibility 
for ad- 


ditional 
circuitry 
also 
involves 
driving 
inductive 
loads. 
When 
the load is highly 
inductive, 
a possi- 


bility exists that reliable 
operation 
of the SSR may 


not occur 
because 
of incorrect 
values 
for the dv/dt 


(a 
complete 
description 
of 
this 
phenomenon 
is 
available 
in various 
publications 
available 
from the 
manufacturers 
of 
the 
solid 
state 
relay 
devices). 
Provision 
has been made 
for installation 
of an ex- 


ternal 
snubber 
network 
should 
this 
be required. 
Again, 
our oven control 
system will not require 
this 
type of circuitry. 
Figure 
18 is provided 
for refer- 


ence should 
the reader 
desire to see the location 
of 


the additional 
components 
on the panel. 
It should 


be noted 
that 
the component 
placement 
does 
not 


allow the installation 
of the MOY and the snubber 
simultaneously. 


mm 


SOLID 
STATE 
RELAY 


We can now get back 
to the task of assigning 
ad- 
dresses 
to the various 
digital channels. 
The iCS 930 


panel 
has three connector 
options 
for connecting 
it 


to the computer's 
I/O 
ports. 
The 
standard 
con- 
figuration 
utilizes 
connector 
12 to attach 
the rib- 
bon 
cable assembly. 
When 
this is done, 
the com- 
puter ports A and B will correspond 
to the 16 chan- 
nels on the terminator 
panel (Figure 
19). If we look 


at the termination 
panel, 
we will see that there is a 


provision 
for the user installation 
of two additional 
ribbon 
connector 
sockets 
onto 
the 
board. 
These 


are used in order 
to utilize the computer 
port C. If 


connector 
13 is installed 
and utilized 
instead 
of 12, 


the channel 
assignments 
will be as shown 
in Figure 


20. In a similar 
manner, 
connector 
Jl 
can be in- 
stalled and utilized 
to provide 
connections 
between 
the computer 
port C and the other 
eight SSR posi- 


tions. 
If we choose 
the 16 lines required 
for driving 


the indicator lamps from the iCS 920 panel to be 
ports A and B, then it seems reasonable tO,assign 
the eight remaining lines required on the iCS 930 to 
port C. A feature of utilizing standard ribbon cable 
assemblies is the ability to easily add ribbon plug 
connectors 
to the cable. This will result in an 


assembly transferring ports A, Band C to the iCS 
920 panel (however, port C is ~ot used) and which 
continues the port C signals to the iCS 930 panel. 


Individual channel assignments can now be made, 
grouping the inputs and outputs together in groups 
of four (this is done because of a requirement of . 
the single board computers to share terminator and 
driver component packages in groups of four). Fig- 
ure 21 provides a drawing showing the channel 
assignments 
and 
the 
physical 
wiring 
locations 


which will be used to connect the oven heaters and 
switches. 
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Final Channel 
Assignments 


The only task remaining 
before 
we have completed 


OUi Lask of assigning 
channel 
numbers 
and physical 


wire 
and 
component 
locations 
is to assign 
these 


channels 
on the iCS 920 digital 
termination 
panel. 


Since we have already 
determined 
that we will uti- 


lize ports 
A and 
B, this becomes 
a simple 
matter, 
requiring 
only 
an 
arbitrary 
assignment 
of 
lamp 


locations 
using 
these 
port 
bits. 
The 
assignments 


made 
for one oven can be seen in Figure 
22. The 


entire 
ladder 
diagram 
of the system 
can 
now 
be 


completed 
along 
with port 
assignments 
for all sig- 


nals used. The completed 
diagram 
can be found 
in 


Appendix 
B. Note 
how the port 
assignments 
have 


been shown 
to the side of the ladder 
element 
repre- 
senting 
that 
interface 
device. 


The 
method 
used 
to 
define 
a port 
assignments 
needs 
to be clarified 
since it may not be apparent 


why a channel 
of port 
A was given the address 
of 


E80. To begin, 
we have already 
indicated 
that each 


port 
consisted 
of eight 
channels 
or bits. 
We will 


number 
these bits from 0 to 7. Since it is possible 
to 


have 
many 
input/output 
devices 
connected 
to the 


computer, 
the possibility 
exists of having 
multiple 


devices 
which 
incorporate 
internally 
ports 
A, 
B, 


and C. The computer 
has been designed 
to support 


up to 256 of these ports so we have numbered 
them 


using the hexidecimal 
numbering 
system. 
The pos- 


sible port numbers 
can then range from 00 to FF. It 


will be found 
that a common 
characteristic 
of most 


single board 
computers 
is the use of assigning 
the 


port addresses 
of E8, E9, and EA to the on-board 


8255 parallel 
peripheral 
interface. 
Therefore, 
the 


first channel 
of port A would 
be defined 
as having 


an address 
of E80; 
the second 
channel 
of port 
B 


would 
be E91, and so forth. 


III. 
SELECTING 
THE COMPUTER 
BOARDS 


To this point 
we have delayed 
the selection 
of the 


boards 
which will be required 
to provide 
the com- 


puterized 
control 
system. 
The 
Intel 
OEM 
Micro- 


computer 
Systems 
Configuration 
Guide 
has been 


designed 
to simplify 
the task 
of selecting 
the re- 


quired 
system. 
Our 
first task is to enter 
all known 


information 
describing 
our desired 
system 
into the 


project 
configuration 
worksheets. 
These 
work- 


sheets 
can then 
be used to actually 
select a board 


configuration 
which 
meets 
our particular 
require- 


ments. 
The effort 
required 
to accomplish 
the entry 


of data is reduced 
to a minimum 
through 
the use of 


predefined 
digital 
and analog 
configuration 
work- 
sheets. 
Our 
requirement 
of having 
a total 
of 24 


parallel 
data 
lines, consisting 
of a mix of high and 


low 
level 
interfaces, 
can 
be 
met 
by 
the 
24-bit 


AC/DC 
combination. 
Our 
assignments 
of 
re- 


quirements 
for the terminator 
panels 
can be made 


and 
is shown 
in Figure 
23. It can clearly 
be seen 


from 
the worksheets, 
that 
our 
required 
interface 


with 
the computer 
digital 
data 
will consist 
of one 


24-bit 
wide 
connector 
(had 
we not 
used 
port 
C 


assignments, 
the 
use 
of 
16-bit 
wide 
connectors 


would 
have sufficed). 
This means 
that our selected 


single 
board 
computer 
or 
1/0 
expansion 
board 


must provide 
at least one edge connector 
having 24 


1/0 
bits on it. 
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DIGITAL CONFIGURATION WORKSHEET 


PROJECT__ 
. 
_ 


This worksheet 
will provide the required digital 
interface configuration 
data which is required to complete the Project Configuration 
Worksheet. 


Enter Number 
of Channels 


Enter # of Discrete AC Outputs (115-230 VAC) 
Enter # of Discrete AC Inputs (115-230 VAC) 
. 


Enter # of Discrete DC Outputs (Current> 
300 MA) . 


Enter # of Discrete DC Outputs (Current 
< 300 MA) . 


Enter # of Discrete DC Inputs 


~(A) 


~(B) 
.. ---.0...... (C) 
.. -.litL(D) 
.. --.0-. 
(E) 


Compute 
the Number 
of iCS 920'· and iCS 930'· Termination 
Panels 


First compute the number of Parallel 1/0 ports (8-bits each port) required 
on your iSBC" board. Round all computations 
up to the nearest whole 


integer unless instructed otherwise' 


Compute # of iCS 930 Interface Output Ports ((A +C)/8) 
.........•. 
Compute 
# of iCS 930 Interface Input Ports (B/8). 
Compute 
# of iCS 930 Termination 
Panels ((F+G)/2) 
Compute 
# of iCS 920 Interface Output Ports (0/8) 
.............•....... 


Compute # of iCS 920 Interface Input Ports (E/8) 
. 


Compute 
# of iCS 920 Termination 
Panels ((J +K)/3) 
. 
. 
. 


.... --i..- 
(F) 


.._~(G) 
..-L(H) 
.. ....2.- 
(J) 


.. 
~(K) 
---1_ 
(L) 


Optimization 
of Digital I/O Port Usage for Minimum 
I/O Configuration 


Compute 
# of iCS 930 Output "Overflow Channels" DO NOT ROUND OFF) 


(A+C)/8 
.. 
QUOTIENT... 
~(M) 


(Overflow Channels) 
REMAINDER 
~ 
(N) 


Compute 
# of ICS 930 Input Overflow Channels (DO NOT ROUND OFF) 


(B/8).... 
.. 
QUOTIENT 
+(P) 


REMAINDER 
.-1- 
(R) 
Compute 
# of iCS 920 Output Overflow Channels (DO NOT ROUND OFF) 


(0/8) 
QUOTIENT.. 
. ~ 
(S) 


REMAINDER 
..........•.. 
--.0....... 
(T) 


Compute 
# of iCS 920 Input Overflow Channels (DO NOT ROUND OFF) 


(E/8).. 
QUOTIENT.. 
.. .. ~ 
(V) 


REMAINDER 
. ----Cl..-(W) 
Compute 8-Bit Input Ports Required (P +V) . 
.. ----Cl..- (X) 


Compute 8-Bit Output Ports Required (M +S)........................... 
.. --2.- (Y) 


Compute 4-Bit Output Ports Required ((N +T)/4) 
(ROUND UP) ......•........ 
.. ----'- 
(Z) 
Compute 4-Bit Input Ports Required ((R +W)/4) 
(ROUND UP). 
. ..•............ 
----'- 
(AA) 


Compute 8-Bit Port C Requirements ((Z +AA)/2) (ROUND UP) 
_1_ 
(BB) 


Total 1/0 
Parallel Ports Required (X +Y+BB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
.. ~ 
(CC) 


Total # of 24 Channel Parallel 1/0 
iSBC Board Edge Connectors 
(CC/3) 
(ROUND UP TO INTEGER) . 
. .. ----L- (DO) 


Compute 
Power Requirements 
for the Termination 
Boards 


(DO 
NOT ROUND 
OFF) 


Compute +5V for iCS 920 Board Outputs (.061 x D) ..........•. 
. ~ 
(EE) 
Compute +5V for ,CS 920 Board Inputs (.023 x E) 
--.0.. 
(FF) 
Compute +5V for iCS 930 Board Outputs ((.020 x (A +C)) 
stf:l:L (GG) 
Compute +5V for ICS 930 Board Inputs (.012 x B) .............•.•....•........... 
~ 
(HH) 
Compute ,CS 920 Power ReqUirements (EE +FF). 
.. ~ 
(JJ) 
Compute iCS 930 Power Requirements (GG+HH) 
.J.Z:?2. (KK) 


Enter the appropriate 
data into the Project 
Configuration 
Worksheet 
as shown 
below: 


The required power requirements of the termina- 
tion panels can be calculated using the data pro- 
vided in the digital configuration 
worksheet. The 


information 
regarding 
the necessary connectors 


and 
the 
power 
requirements 
should 
then 
be 


transferred to the project configuration worksheet 
(Figure 24). 
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A similar technique is used to configure the analog 
signals using the standard 
analog configuration 


worksheet as shown in Figure 25. It can be seen 
that our application will require a single cable con- 
nection to a differential input edge connector of an 
analog input board. The power requirements can 
be calculated 
from the current 
requirements 
to 


drive the thermistors and the sensing resistors. The 
data is entered into the appropriate columns of the 
configuration 
tables and then transferred 
to the 


project configuration 
worksheet. 


ANALOG CONFIGURATION WORKSHEET 


PROJECT 
().E)J <DUJ!1Q..LEP- 


~:::; : :: ~;,~.~lf:~I~~i~~II~~:~n~~~~h~~~:~·11 
±::: 


Enl'"01 
O,II••• "till 
low 
LlY" An,lOll Ch,nn.ls 
-O-(C) 
Ent.,. 
01 "".logOutp",, 
Voll.goe CI.,"nell.. 
. 
-0-(0) 


Ent.,.ol"n.logOull>ulCUff."tC' 
••nn,I, 
-D.-IE) 


Comput. the NumtNr oIISBC·· Bo.rd Edg. Conn.ctors 


UnIeuOlh_, 
•• nolecl.tound.JlcornP!Jl.tions.OI" 
••••• II"II••"nl~ 
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The only remaining physical element of our control 
system which we have not defined is the CRT ter- 
minal which will be used for setpoint entry and 
modification. 
Communications 
with a terminal re- 


quires that we provide a serial RS232C port in our 
control system. This port requirement is entered 


onto the worksheet and the system requirements 
are totaled as shown in Figure 26. 
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Figure 26. 


We must now choose the Intel iSBC boards which 
will provide a solution to our system requirements. 
This is done by referencing the summary of key 
iSBC configuration 
parameters 
to 
find 
boards 


which provide the necessary characteristics. 
Our 


first task is to choose a single board computer 
which meets as many of our needs as is practical, 
while providing performance 
characteristics 
ade- 


quate to our needs. 


Our first requirement 
for having support 
for a 
single RS232C serial communications 
channel can 


be seen to be met by a variety of possible boards. 
Among the possible boards meeting this require- 
ment are: 


iSBC S6/12™ 
iSBC SO120™ 
iSBC SO/30™ 


We must look further before a final choice can be 
made. Again, it can be seen that all candidates also 
meet the requirement of providing a minimum of 
one 24-bit wide digital I/O connector. Our decision 
must be based upon 
parameters 
which are not 


necessarily related to the input or output capabili- 
ties. Even though we have not yet developed our 
software package for our control system, we can 
safely make some assumptions regarding the com- 
pleted software package and thus define additional 
requirements 
which will enable us to select our 


desired computer board. The software task will be 
considerably simplified if we write our programs in 
a high level language and if we use available drivers 
for our input and output where they are available. 
As we will see, the utilization 
of PL/M 
and 


RMX/SO™ real-time 
executive and 
drivers will 


make this programming task much less demanding 
of our time. The trade-off is that these software 
tools take larger amounts of memory than if we 
were to write our entire application 
program 
in 


assembly language. Let us make an initial estimate 
that our system will require about SK of EPROM 
and in the neighborhood of 2K of RAM. 


iSBC SO/IONM 
iSBC SOI20-4™ 


Entering this data on the configuration 
worksheet 


(Figure 27) enables us to narrow our choice by 
eliminating the iSBC 80/l0A since it does not have 
sufficient RAM on board. 


Since our application is not likely to require exten- 
sive math handling capabilities or high speed capa- 
bilities, we probably do not need the power found 
in the iSBC 86/12; so we will remove this product 
from consideration. 


We are now faced with selecting either the iSBC 
80120 board or the 80/30 board for our processor. 
Each has certain advantages and disadvantages for 
use in our application. 
Let's compare these two 


boards, considering first the iSBC 80120, then the 
iSBC 80/30. 


iSBC 80120 board advantages - 
Slightly lower 


cost, greater number of 1/0 lines available. 


iSBC 80/30 board advantages - 
Faster proces- 


sor, dual ported 
memory, able to utilize UPI 


modules. 


If the system were to operate in a stand-alone en- 
vironment and we could be certain that significant 
expansion would not take place, we would prob- 
ably choose the iSBC 80120 computer for our ap- 
plication. 
If we consider that the system might 


become a part of a much larger system by future 
expansions 
and additions, 
we should remember 


that the use of the UPI modules on the iSBC 80/30 
computer 
provides 
considerable 
power 
through 


multiprocessing 
capabilities. 
The 
dual 
ported 


memory can also provide us with the ability to use 
more 
sophisticated 
inter-board 
communication 


protocol should the need arise. For the purposes of 
this application note, we will assume the system is 
being designed for expansion and we will select the 
iSBC 80/30 computer. 


A good design practice is to provide an extra mar- 
gin of available memory in the hardware design. 
Our anticipated 
RAM memory will use about 2K 


bytes. The computer will provide us with 4K bytes 
so we have a considerable margin. This is not true 
when we look at the amount of EPROM available 
on the board. Our 8K requirement is identical to 


the amount 
of memory available 
to us on the 


board. We should consider the use of an expansion 
EPROM board or the prospect of having to spend 
a considerable amount of time reworking our pro- 
gram to get it to fit if we find that we have exceeded 
our estimates. We will select the option of adding a 
memory expansion board (it can be deleted if we 
find that our software requirements are less than 
estimated). 


The computer selection and the memory expansion 
board data can now be entered onto the configura- 
tion worksheet as shown in Figure 28. If needed, 
the addition of the memory expansion board will 
allow our EPROM requirpf!1ents to grow up to 16K 
bytes. 
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The only requirement which we have not met is to 
assign a board to handle the analog input needs of 
our temperature sensing circuit. The analog voltage 
can be calculated and will be found to lie in the 
neighborhood 
of 4.6 volts at room temperature. 


This value will increase toward 
5 volts as the 
temperature 
of the oven increases. Since we have 


no requirement for any analog output capabilities, 
we will choose the Intel® iSBC 711™ Analog Input 
Board to sense the voltage level. This board can be 
configured to handle a 5-volt full scale input and 
will provide a resolution of 12 bits. (If an oven re- 
quiring a wide range of temperatures 
and greater 


resolution were required, we would have to recon- 
figure our temperature 
sensor to provide a wider 


voltage spread over operating 
temperatures. 
For 


purposes of simplicity and clarity we will assume 
that our temperature resolution is adequate.) 


The configuration 
worksheet can be filled in to 


reflect the selection of the analog converter and the 
total power requirements 
for the system can be 


computed as has been done in Figure 29. We now 
need to select a chassis and power supply in order 
to complete the application hardware design phase. 


The Industrial Chassis 


Before the boards can be operated together to [0' ('1 
a control system, a means of allowing communica- 
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tion between the boards and of distributing power 
among the boards must be found. This require- 
ment is met by specifying a chassis into which the 
boards will be mounted. 
The Intel® iCS 80n, In- 


dustrial Chassis provides an environment for oper- 
ating the boards which is specifically designed to 
operate in an industrial area. 


The chassis has been designed to facilitate mount- 
ing into either a standard 19-inch RETMA cabinet 
or it may be rear-panel mounted into an enclosure 
such as may be found in applications requiring the 
use of a NEMA electrical enclosure. The card chas- 
sis has been mounted in such a manner as to hold 
the single board computers and expansion modules 
vertically, 
facilitating 
maximum 
cooling 
of the 
boards. Fans are provided to aid the normal con- 
vection cooling process. Card racks may be in- 
stalled into the iCS 80 chassis to expand the card 
support capability to a maximum of 12card slots in 
groups of four. Either an iSBC 635 or 640 power 
supply can be mounted into the industrial chassis 
to provide power up to 4 or 12 boards capability, 
respectively. 


[ r- 


, 
T 
il=-- c- 
---f-- 


f--I- 
[--I- 


-;~ 


I 
I 
I 
I 


r 
I.f::::t~o. 
I ~~~\~;:LE 


SUIIM 


CMlIIIS itS 
WJ-~ 


CUO'*'l 
P1IWtI",m, 


Our application design requires the installation of a 
three boaTd solution, so we will choose the iCS 80 
chassis with one iSBC 635™ power supply. We will 
choose to mount our control system in a standard 
NEMA 12 enclosure to protect the unit from the 
industrial environment. We should refer to the iCS 
80 Industrial System Site Planning and Installation 
Guide (manual order number 9800798) for com- 
plete details for selecting appropriate 
enclosures 


and installation instructions. 


The + 5 volt power needed to support the various 
termination panels and to supply a reference volt- 
age for the thermistors is available from a barrier 
strip located on the lower front 
of the iCS 80 


chassis (Figure 30). Our wiring can be routed to 
this barrier strip for those circuits requiring either 
5-volt DC or the system logic common. 
A fuse 


holder is provided and a fuse should be installed 
for system protection. We will install a 2-amp fuse 
into the holder (our maximum power requirement 
for external circuitry should be 1.22 amps accord- 
ing to Figure 26). 


The 
remaining 
terms 
required 
in our 
ladder 
dia- 


gram 
(Appendix 
B) consist 
of 
a 
high 
voltage 
neutral 
and 
a 
source 
of 
switched 
high 
voltage 
power for the heater lamps. 
Both of these terms are 


available 
from 
the iCS 80 industrial 
chassis. 
It is 


desirable 
to utilize 
the same 
switched 
power 
for 
both 
the computer 
system and our external 
signals, 
so 
that 
we can 
provide 
protection 
to 
operators 


when 
one 
portion 
of the system 
is shut 
down. 
A 


common 
source 
will insure 
that all portions 
of the 


system 
are inactivated 
if repair 
is being done. 
The 
iCS 80 chassis 
incorporates 
a heavy duty industrial 
key-lock 
switch 
for its power 
switching. 
The out- 
puts of this switch are available 
to the user at a ter- 
minal 
barrier 
strip 
located 
on a fold-out 
panel 
on 
the rear of the chassis assembly 
(refer to Figure 31). 
We can 
see that 
our 
neutral 
wire should 
be con- 
nected 
to terminalS 
(filtered 
AC low) and the wire 


for the AC high, 
wire #10 on the ladder 
diagram, 


should 
be connected 
to terminal 
9. This 
will pro- 


vide us with a switched, 
fused, 
and 
filtered 
power 


source 
for our external 
wiring. 


As we will be installing 
the chassis 
into a NEMA 


enclosure, 
we will not want to use a standard 
power 
cord 
since 
this 
would 
involve 
the 
additional 
ex- 
pense 
of installing 
a duplex 
outlet 
in the cabinet. 


The power 
wiring can be installed 
directly 
onto 
the 


power 
barrier 
strip 
by placing 
the AC hot wire on 
barrier 
number 
1, the 
neutral 
wire 
onto 
barrier 
number 
4, and the ground 
onto 
barrier 
number 
3. 


The 
hardware 
implementation 
of the system 
can 
now be considered 
to be complete. 
Before 
the sys- 
tem can function 
as a control 
for the oven temper- 
atures, 
we must 
define 
the relationships 
between 
the various 
pieces of the oven system 
and we must 
also define 
the operator 
interface 
with the CRT ter- 
minal. 
Thus, 
we begin 
the software 
phase 
of our 
design. 


IV. 
DETERMINA 
nON 
OF sonw ARE 


APPROACH 


The task of providing 
the relationships 
between 
the 


various 
system 
components 
falls into the category 


of writing 
the software. 
Before we actually 
begin to 


develop 
this software, 
we will define 
certain 
guide- 
lines which 
can 
be used 
to organize 
and 
simplify 


the task. 


Let 
us 
consider 
the 
general 
environment 
under 


which our programs 
will operate. 
We find that we 


have essentially 
two choices 
in this area. 
First, 
we 
can consider 
the entire process as a sequential 
set of 


predefined 
operations 
in which 
we must 
perform 
each 
operation 
before 
moving 
to 
the 
next 
until 
finally 
we complete 
the sequence 
and begin again. 


(This is analogous 
to using a single stepper 
switch 
to design our control 
system.) 
Since each oven is in- 
dependent 
of the others, 
we can not afford 
to use 


this approach 
since we could get tied up waiting 
for 


something 
to 
happen 
in a 
particular 
oven 
and 


would 
have to ignore 
the other ovens. 
The designer 


familiar 
with 
relay design 
will probably 
be think- 


ing, 
at this 
point, 
that 
we should 
use a separate 


sequential 
operation 
for each oven or device to. be 


controlled. 
Indeed, 
this is exactly 
what 
we can do 


with our software 
by using what is known 
as a real- 


time 
executive. 
This 
tool 
will allocate 
the 
com- 


puter's 
resources 
in such a manner 
as to provide 
us 


with the capability 
of having 
independent 
software 


programs 
or tasks operating 
at what appears 
to be 


the same time. 
We will make 
our first assumption 


that our software 
will be written 
using such a tool 


and 
we will 
specify 
that 
we will operate 
under 


Intel's 
RMX/80 
Real-Time 
Multi-Tasking 
Execu- 


tive. 
We will discuss 
more 
detail 
of this software 
tool as we develop 
our programs. 


Next, 
we must consider 
the language 
which we will 


use to actually 
define 
our required 
operation. 
We 
have many 
alternatives 
from which to choose. 
Let 


us look at several of the alternatives 
in some detail. 


Assembler 


Assembler 
language 
is probably 
the most basic tool 


with which we can program 
a computer. 
It is con- 


sidered 
to be the most 
efficient 
user of program 


memory 
and 
processor 
time. 
These 
features 
are 
made 
possible 
because 
each 
assembler 
instruction 


line 
is 
converted 
directly 
into 
a 
corresponding 
machine 
instruction. 
From 
a programming 
stand- 
point, 
assembler 
language 
is the most 
difficult 
to 
use since any task must 
be defined 
by subdividing 
that 
task 
into 
a multitude 
of smaller 
operations 
compatible 
with 
the available 
instructions 
of the 
computer. 
To use this language, 
we must be famil- 


iar 
with 
the 
architecture 
of each 
computer 
with 


which we desire to operate. 
The use of the language 
is somewhat 
simplified 
through 
the use of an Intel 


supplied 
assembler 
which 
converts 
the assembler 


code 
into 
machine 
instructions 
and 
provides 
list- 


ings of the operations 
which have been entered. 
A 
complete 
description 
of 
the 
Intel 
8080/8085 
As- 


sembler 
Language 
is available 
in the 8080/8085 


Assembly 
Language Programming Manual (man- 


ual order 
number 
9800301 B). 


The 
user 
should 
consider 
this programming 
tool 


when 
his 
application 
requires 
the 
minimum 


amount 
of memory 
(such as might 
be required 
for 


very large volume 
designs 
where 
memory 
cost is a 
factor) 
or where 
a highly 
time dependent 
routine 


must be defined. 
Our oven application 
does not fall 


into 
either 
of these categories, 
so we will choose 


not to use this language 
in our instance. 


PLiM 


Intel's 
PL/M 
language 
offers 
an efficient, 
struc- 


tured, 
high 
level systems 
programming 
language. 


Before proceeding, 
let us be clear on the benefits 
of 


using a high level language. 
First, 
the use of high 


level languages 
results in reduced 
development 
time 


and 
cost. 
High level languages 
provide 
the ability 


to program 
in a natural 
algorithmic 
language. 
In 
addition, 
they eliminate 
the need to manage 
regis- 


ter usage or to allocate 
memory. 
Second, 
high level 


languages 
provide 
improved 
product 
reliability 


because 
programs 
tend to be written 
in structured 


formats 
and 
result 
in a minimum 
of extraneous 


branches 
which 
might 
cause 
testing 
problems. 


Finally, 
their use produces 
programs 
which are bet- 


ter documented 
and are easier 
to maintain. 


On the other 
hand, 
high level languages 
do not op- 
timize the code segments 
as well as can be done by 


an experienced 
assembly 
language 
programmer. 
As 


a result, 
most 
compilers 
(routines 
which 
convert 


the 
high 
level languages 
into 
machine 
executable 
code) use more program 
storage 
than those written 


by the assembly 
language 
programmer. 
Different 


languages 
and compilers 
require 
different 
amounts 


of memory 
for the same task. 


PUM-80 
is probably 
one of the most efficient 
high 


level languages 
for use on microcomputers. 
It has 


been determined 
that PL/M-80 
users can expect to 


use between 
1.1 to slightly 
more 
than 
2 times 
as 


much 
program 
memory 
as would 
be used 
for the 
same 
task 
written 
in assembly 
language. 
For 
this 


reason, 
we must place the use of this language 
high 


upon 
our list of possible 
languages 
in this applica- 


tion. 


A glance 
at the PL/M-80 
Programming 
Manual 


(manual 
order 
number 
98-2688) 
indicates 
that 
the 


language 
is highly 
structured 
and 
seems 
to lend 
itself very well to handle 
logical type operations. 
It 
seems 
to have 
the greatest 
weakness 
in its math 


handling 
capabilities 
in that 
it does 
not 
support 


negative 
numbers 
or fractions. 
It is reasonable 
to 
assume 
that 
the oven 
application 
can be handled 
entirely 
with 
positive 
integer 
numbers 
so 
this 


limitation 
will not unduly 
hamper 
our use of this 


language. 
We will keep these features 
in mind when 


making 
a final decision. 


FORTRAN 


Intel's 
FORTRAN-SO 
provides 
the 
full subset 
of 


ANSI 
FORTRAN 
77. In many 
cases FORTRAN- 


SO has features 
that 
exceed 
the specifications 
for 
both the subset and the full versions 
of FORTRAN 


77. Most 
of the power 
of this language 
lies in its 
ability 
to easily handle 
complex 
mathematical 
ex- 


pressions. 
Obviously, 
it does not have any limita- 


tions regarding 
fractions 
or sign of the numbers 
in- 


volved. 
It should 
be used when the application 
re- 
quires 
the use of mathematical 
computations. 
The 
power 
of the language, 
however, 
means 
that 
the 
use of the language 
will take a heavy toll of mem- 


ory allocation. 
A complete 
description 
of the FOR- 


TRAN 
version supported 
by Intel and its use on the 


iSBC computers 
can be found 
in the FORTRAN- 
80 Programming Manual (order number 
9S0048 IA) 
and in the ISIS-II FORTRAN-80 
Compiler Opera- 


tor's Manual (order 
number 
9800480). 


It is unlikely 
that 
the magnitude 
of mathematical 


routines 
required 
to control 
the temperature 
of our 


ovens will be complex 
enough 
to justify 
the use of 
FORTRAN. 
Keep in mind that, 
if such a situation 


were encountered, 
it is feasible 
to use a cbmbina- 
tion of programming 
languages 
to create 
our final 
module. 


BASIC 


Certaintly 
the most well known 
high level program- 
ming 
language 
today 
is BASIC. 
It offers 
a quick 


way of applying 
the computational 
capabilities 
of 


the computer 
to a wide range 
of applications. 
The 


Intel RMX/SO 
BASIC-80 
is an interpreter 
designed 
to operate 
with Intel's 
single board 
computers 
and 


contains 
extended 
disk handling 
capabilities. 
As an 


interpreter, 
it differs 
from 
other 
high 
level lan- 


guages 
in that it results 
in a relatively 
slower oper- 


ating solution 
to an application. 
It is also not possi- 
ble to use BASIC 
to generate 
multiple 
independent 


tasks 
which 
can compete 
for computer 
resources. 


For 
these 
reasons, 
we cannot 
consider 
the use of 
BASIC 
for a solution 
to our application. 


Final Selection 
of Language 


From 
the above 
discussion, 
it seems clear that our 
choice 
for the application 
being demonstrated 
is to 
use PL/M-SO 
as our programming 
language. 


With this in mind, 
we can begin the task of actually 
generating 
the code which will complte 
our applica- 


tion and provide 
an operating 
control 
system. 


v. DEFINING 
SOFTWARE 
TASKS 


The software 
implementation 
can begin as soon as 
we have 
broken 
our 
control 
functions 
into 
inde- 


pendent 
"tasks". 
We can 
then 
handle 
each 
task 
separately 
as though 
it were the only thing 
which 


had to be done by the control 
system. 
In the event 
that we find that one of our tasks must communi- 
cate with 
or be interlocked 
with 
another, 
we will 
handle 
this need through 
the use of "exchanges". 


The "exchange" 
can be thought 
of as a mailbox 
in- 
to which messages 
are deposited 
and picked 
up by 


the various 
tasks. These messages 
convey the neces- 


sary information 
between 
the otherwise 
independ- 


ent programs. 
When all tasks have been coded, 
we 
will combine 
them using the facilities 
of RMX/80. 


Our 
oven 
application 
can 
be broken 
down 
into 


three 
functional 
areas 
or tasks. 
These 
are: 


I. The Control 
Task which will be used to actually 
sense 
the oven temperature 
and 
to provide 
the 


required 
responses 
to the heaters 
and 
the indi- 


cator 
lamps. 


2. The CRT Update 
Task will be used to provide 
a 


"snapshot" 
of the system 
operations 
to a per- 


son viewing 
the CRT 
terminal. 


3. The Parameter 
Update 
Task 
will be used to ex- 


amine 
and update 
the oven setpoints 
and toler- 


ances. 


The choice of these three tasks has been essentially 
arbitrary 
in nature. 
Certainly, 
other 
choices 
and 


groupings 
of 
functions 
could 
easily 
have 
been 


made. 
We will use these choices 
for our example 


and 
will proceed 
with 
our 
development 
accord- 


ingly. 


We have two other supporting 
tasks which must be 


included 
in our system. 
Fortunately, 
these tasks are 


predefined 
and 
fully supported 
within 
RMX/80's 


libraries; 
thus 
we need 
not write 
these 
functions. 


The two supporting 
tasks are: 


4. A Terminal 
Handler 
Task to support 
the actual 


interface 
to the CRT terminal. 
It provides 
echo 


of 
input 
characters 
and 
signals 
when 
data 
is 


ready 
to be read. 
It will output 
messages 
to the 


terminal 
and 
signal 
when 
all 
characters 
re- 


quested 
have been sent. 


5. An Analog 
110 Driver Task to request 
and han- 
dle 
the 
handshaking 
which 
is 
required 
to 


communicate 
with 
the analog 
input 
board. 
It 


will signal 
us when 
data 
has been 
input 
and 
is 


available 
for use by our user written 
tasks. 


We can proceed 
with 
the implementation 
of each 


of our three tasks which we have defined. 
The first 


step with each will be to develop 
a flowchart 
which 


shows 
the required 
operations 
to implement 
that 


task. 
This 
flowchart 
will show any intertask 
com- 


munications 
or 
exchanges 
that 
may 
be required 


with other 
tasks. 
The flowchart 
can then be coded 


using 
the facilities 
provided 
by our 
programming 


language. 


Oven Control 
Task 


The 
sequence 
of operations 
required 
to perform 


the control 
task can be defined 
using the flowchart 


shown 
in Figure 
32. Let us examine 
the required 


steps in more detail. 


those tasks to test for the presence 
of a message 
at 


the exchange 
before 
they get the temperature 
data. 


If no message is present, 
they must wait until one is 


placed 
into 
the exchange 
before 
proceeding. 
Just 


before 
we update 
the temperatures 
we will fetch the 


message 
from the exchange, 
leaving 
it empty 
while 


we work on the data. 
later we will again restore 
the 


message 
when 
the update 
is complete. 


An arbitrary 
decision 
has been made 
to only sam- 


ple and 
control 
the ovens 
once each second. 
This 


will allow some time for the system to respond 
once 


a heater 
output 
has been set. The first step in our 


control 
task is to wait for one second 
to elapse. 


Our next subtask 
should 
be to read the status of the 


various 
oven 
control 
switches 
on 
the 
operator's 
control 
panel. 
This 
item 
could 
wait 
until 
a later 


time, 
but 
there 
is no harm 
in handling 
it at this 
time. 


Next, 
we see a block 
indicating 
the input 
of data 


regarding 
the current 
oven temperatures. 
This oven 


temperature 
data will certainly 
be used by the task 


handling 
the snapshot 
display 
on the CRT 
so we 


must give some consideration 
to the validity 
of the 


data. 
While 
we are in the process 
of getting 
the 


data 
and 
converting 
it to engineering 
units 
(next 


step), 
there will be periods 
during 
which the stored 


temperature 
data 
does 
not reflect 
the actual 
oven 


temperature. 
An example 
might be when we are ac- 


tually 
moving 
the 16 bits of the temperature 
since 


we can only move data 8 bits at a time. During 
this 


period, 
we would 
not want another 
task to use the 


data 
and since each task is going 
to operate 
inde- 


pendent 
of others, 
we must 
provide 
some 
type of 


lockout 
of the data 
while we are operating 
on the 


temperatures 
(an alternative 
would be to have each 


task 
get its own 
temperature 
from 
the AID 
con- 


verter 
and convert 
it to engineering 
units, 
but this 
would 
seem to waste memory 
and computer 
time). 


We 
can 
provide 
this 
lockout 
by creating 
an ex- 


change 
to communicate 
with 
other 
tasks. 
If we 


make a message available 
in this exchange 
when the 


data is valid and cause no messages 
to be available 


when 
the data 
is nonvalid, 
we can effectively 
lock 


out tasks from using the data when it is in the pro- 
cess of being 
updated. 
This 
is done 
by requiring 
Figure 32. Control Task Flowchart 


The 
number 
obtained 
from 
the analog 
converter 


provides 
us with a value 
which 
is proportional 
to 


the temperature 
of the oven. 
Our 
next step 
is to 


convert 
this number 
into engineering 
units. 
Unfor- 


tunately, 
the 
voltage 
and 
temperature 
are 
not 


related 
in a linear 
fashion 
since the thermistor 
is a 


nonlinear 
device. 
We will have to develop 
a tech- 


nique to obtain 
a corrected 
value. 
For the purposes 
of this application 
note and in an attempt 
to keep 


the 
application 
as 
simple 
as 
possible, 
we 
have 


chosen 
to utilize a single table look-up 
to perform 


this 
conversion. 
Alternatives 
might 
have 
been 
to 


utilize FORTRAN 
routines 
to mathematically 
per- 


form 
the conversion 
or to have separate 
tables 
for 


each oven. Once the conversion 
has been made, 
we 


must return 
a message to the data lockout 
exchange 


to allow other 
tasks access to the data. 


Because 
we must deal with four ovens, 
the opera- 


tions 
related 
to each individual 
oven must be per- 
formed 
four 
times, 
once 
for each. 
This 
is easily 
handled 
as we will see, since PL/M 
is a block struc- 


tured language. 
Our flowchart 
need only remind 
us 


that 
the operations 
need be done 
four times. 


The next step has been defined 
as performing 
some 


digital 
filtering 
of the temperature 
by averaging 
the 


current 
temperature 
with 
the temperature 
of one 


second 
ago. This filtered 
value will be used to per- 


form subsequent 
computations 
and to make future 


decisions. 


We 
have 
defined 
earlier 
in our 
definition 
of the 


control 
algorithm 
that 
we would 
use a derivative 


control. 
We have chosen 
to project 
the tempera- 


ture ahead 
for a period 
of 10 and 30 seconds. 
We 


must 
calculate 
the 
rate 
of 
change 
and 
the 


temperatures 
in 10 and 30 seconds 
so that this data 
will be available 
when 
needed. 


Now that the calculations 
have been made to deter- 


mine numeric 
values required 
for the decision 
mak- 


ing process, 
we must begin the process 
of determin- 


ing the status 
of each indicator 
and oven heater. 
A 


test will be made of the oven run switch and if it is 
found 
to be turned 
off, 
we will turn 
off all indi- 


cators 
and 
the 
oven 
heater 
associated 
with 
that 


oven. 
If the switch is found 
to be turned 
on, we will 


set the status 
of the 
"in 
tolerance", 
"caution", 
and "alarm" 
indicators 
according 
to our oven con- 


trol algorithm. 
The oven heater 
will be turned 
on 


or off according 
to the projected 
temperature 
in 30 


seconds. 


Rather 
than 
output 
the individual 
oven 
indicator 


and heater data four times (once for each oven), we 


will 
perform 
the 
computations 
associated 
with 


making 
the 
decisicn 
four 
times 
(this 
saves 
code 
since we can use the same program 
steps with only 


pointers 
being exchanged). 
At the end of this time, 


a single operation 
will output 
the data 
to all ovens 
and 
indicators 
at the same 
time. 
Outputting 
to a 
computer 
port will actually 
cause the device to turn 
on or off according 
to whether 
the output 
bit is a 
one or zero. 


We will then return 
to the beginning 
of our task to 


wait until another 
second 
elapses 
before 
we again 


perform 
the indicated 
functions. 


Control Task Source Coding - 
The coding 
of our 


tasks is a straightforward 
procedure 
once we have 


prepared 
a flowchart. 
Since we are using PL/M-80 
and 
RMX/80, 
the coding 
sequence 
for a task will 


be as follows: 


I. 
Define any variables 
or structures 
which will be 


used in the module. 
This involves 
providing 
in- 


formation 
defining 
variables 
as being either an 8 


or 16-blt variable 
and declaring 
if that 
variable 


is to be a part of the task being coded or is to be 
found 
in some other task. 
If any arrays 
or struc- 
tures are to be used, they must also be defined. 
Finally, 
if any program 
locations 
are to be used, 


they must be declared. 


2. The task must be initialized. 
That 
is to say that 


any assumptions 
which will be made as to initial 


data 
values 
in subsequent 
instructions 
must 
be 


initially 
forced 
to this initial 
value. 


3. The 
actual 
task 
must 
be coded 
to match 
the 


operations 
called out in the flowchart. 


We will look at some examples 
of this coding 
pro- 


cess using the control 
task flowchart. 
The complete 


listing of this module 
and all modules 
actually 
used 


to provide 
the oven control 
system can be found 
in 


Appendix 
C. 


At first glance, 
it would 
seem that the listing is ex- 


tremely 
complex, 
but as we will see it is made up of 


straightforward 
pieces. 
The 
listing 
is made 
up of 


three 
parts 
as we have mentioned 
above 
when de- 


fining 
the steps 
required 
to generate 
a program. 


The first part (line numbers 
1 through 
50) is used to 


define 
parameters, 
variables, 
and 
external 
ele- 


ments. 
The 
general 
types 
of elements 
making 
up 


this portion 
fall into 
typical 
categories. 
The 
first 


general 
category 
consists 
of 
DECLARE 
state- 


ments. 
Examples 
of typical 
lines will help explain 


their 
meanings 
(when 
actually 
developing 
the pro- 
gram, 
this 
first 
section 
was created 
piecemeal 
by 


making 
an entry when it was found 
that a need for 


that 
term existed 
as the execution 
code in sections 
two and three 
were written). 


Examples 
of the 
"declare" 
statement 
are shown 


below. 
For example, 
on line II we find: 


11 
1 
Declare (n,k) byte; 


This means 
that the variables 
"n" 
and "k" 
are be- 


ing defined 
as terms 
which 
represent 
numbers 
or 


data 
which is one byte or 8 bits wide. The" 
II" 
is 


the program 
line number, 
and 
the" 
I" 
jndlcafes 


that we are in the first level of nesti~g. 


We can also see the use of the "literal" 
expressions 
such as used in line 4. The expression: 


4 
1 
DECLARE 
FALSE LITERALLY 
'OOH'; 


means 
that we are creating 
a new _instruction 
called 


"false" 
and that its meaning 
is to be interpreted 
by 
the compiler 
as being 
equivalent 
to, the value 
of 


zero. 


Rather 
than 
dwell on the declaration, 
let us move 
on to the coding 
process 
which was used to gener- 


ate the actual 
program. 
Keep in mind that 
the use 
of PL/M-80 
requires 
that 
all, terms 
used 
be de- 


clared 
in the program 
modul~. 
Refer to the PL/M- 


80 Programming 
Manual 
(order number 
9800268B) 


for a full descriptio~ 
of the PLiM 
language. 


Program Initialization 
- 
The initialization 
portion 


of the program 
can be found 
on lines 51 through 
59 


of the control 
task program 
listing. 
This section 
is 
used to initialize 
data and to provide 
known 
entry 
conditions 
before 
we enter 
the repetitive 
program 


loop. 
This code is only executed 
when the'system 
is 
reset or when 
the power 
is turned 
on. The control 


task requires 
two types of initializations; 
one to in- 
itialize the computer's 
output 
port and the other to 


set up 
the AID 
converter. 
The 
requiremenls 
for 


each 
can be found 
in the RMX/80 
User's 
Guide 


and the iSBC 80/30 
Single Board 
Computer 
Hard- 


ware Reference 
Manual 
(order 
number 
980061IA). 
Actual 
instruction 
examples 
are 
given 
in 
these 


manuals 
for the initialization 
operations. 


Program Body - 
The program 
which actually 
pro- 


vides the control 
operations 
can be found 
on lines 
60 through 
126 of the program 
listing for the con- 


trol 
task. 
It has been 
divided 
into 
sections 
which 


correspond 
directly 
to 
the 
flowchart 
that 
was 
prepared 
earlier. 
Most 
instructions 
in 
PL/M-80 


language 
follow closely the English 
structure 
which 


describes 
what is being done. 
The exceptions 
gener- 


ally 
follow 
definite 
predefined 
formats. 
The 
for- 


mat such as used on line 61 to wait for one second 
to elapse is an example 
of one such exception. 
Any 


time we desire to wait for a definite 
time period, 
we 


use an instruction 
of the form: 


MSG$PTR = RQWAIT 
(.DUMMY$EXCH, 
TIME DELAY); 


Whatever 
time delay we wish to use is expressed 
in 


increments 
of 50 'msec time periods. 
Our example 


requires 
a time delay of one second 
so we will use 


the delay notation 
of 1.010.050 = 20 time units (this 


command 
is actually 
calling llpon the RMX/80 
ex- 


ecutive 
to handle 
the delay). 


The oven enable switch data has been defined 
by us 


to be routed 
by the hardware 
to the computer 
port 


"EA" 
which converts 
to a decimal 
number, 
234. If 
we define an internal 
memory 
location 
for this data 
and 
call 
it BLOCKO, 
then 
we can 
get 
the 
oven 
switch 
data by using an input 
statement. 
Since the 


data sense is inverted 
through 
the hardware, 
we can 


provide 
meaningful 
internal 
data if the signal is re- 


inverted 
as it is loaded 
into memory. 
The instruc- 


tion on line 62 of the control 
task listing performs 


this task. 


We are now ready 
to get the analog 
data 
from 
the 


AID 
converter. 
Our flowchart 
shows that we must 


lock out the other tasks from access to the tempera- 
ture data 
during 
this time period, 
so we must 
first 
remove 
the enable 
message 
from 
the exchange 
in 
which 
it is stored. 
Messages 
are removed 
from 
an 
exchange 
by using an instruction 
of the form: 


STORAGE = RQWAlT 
(EXCHANGE 
NAME,O) 


Line 63 of the program 
listing 
means 
that 
we will 


get a message 
from 
our storage 
exchange 
which 
is 
called 
"Temp$lockout$exch" 
and 
store 
it in 
a 


memory 
storage 
area called 
"Lockout". 
Now, 
no 


other 
task 
can get a message 
from 
this exchange 
since it is empty, 
so it is permissible 
to operate 
on 


the temperature 
data. 
(Note 
how similar 
this com- 


mand is to the one used to wait for a delay. 
Indeed, 


this 
is the same 
request 
for 
RMX/80, 
but 
it re- 


quests 
a time delay of zero.) 


During 
the initialization, 
we built a message 
defin- 


ing the characteristics 
of the analog 
signals and of 


the analog 
conversion 
board 
which 
we are using. 


Remember 
that we have indicatep 
that 
the task of 


getting this data from the board 
is provided 
to us by 


one 
of RMX/80's 
predefined 
drivers. 
All that 
is 


necessary 
at this time is to inform 
that driver of our 


desire to get data, 
then wait until it has done its job 


and 
the data 
is available 
for us. The actual 
com- 


munication 
between 
our applications 
task and 
the 


analog 
driver is done using the idea of an exchange 
similar 
to that 
we have used 
to lockout 
the data. 


We will send a message 
to the analog 
driver 
telling 
it what 
we want 
it to do, then we will wait until it 


sends a message 
back to one of our exchanges 
tell- 


ing us that 
it is done. 
The 
format 
for sending 
a 


message 
to an exchange 
always 
follows 
the form: 


CALL RQSEND (EXCHANGE 
NAME, MESSAGE NAME); 


Line 64 of the listing shows that we have requested 
the input of the analog 
data since we have sent our 


message, 
Convert, 
to the analog 
driver's 
exchange 
which 
is called 
RQAIEX. 
We will wait 
until 
the 


operation 
is complete 
by using 
the 
line 
of code 


shown on the listing line 65. This is the same opera- 
tion type that we used to get our message 
back pro- 


viding a lockout 
earlier. 
The program 
will wait un- 


til a message 
is available 
before 
continuing. 


The data 
must 
now be converted 
into engineering 


units. 
We 
earlier 
indicated 
that 
we would 
use a 


table 
lookup 
to perform 
the linearization, 
so we 
have included 
this table as a part of our program 
at 
line 50. The offset 
into the table corresponding 
to 


our 
temperature 
must 
be determined 
so that 
the 


correct 
value can be stored. 
Because 
we have four 


ovens, 
we will perform 
the operation 
four 
times 
with 
the data 
each 
time corresponding 
to the ap- 


propriate 
oven. 
These 
operations 
can be followed 


on lines 77 through 
81 of the listing. 


Lines 67 through 
76 are used to establish 
an offset 


to be applied 
to the analog 
temperature 
data when 


the 
system 
is running. 
This 
program 
is only 
de- 


signed 
to be used 
during 
the start-up 
operations 
and is activated 
when a message 
containing 
a cali- 


bration 
request 
and current 
temperature 
is sent to 


its exchange. 


The 
temperature 
lockout 
must 
be 
removed 
to 


enable 
other 
tasks to use this data. 
This is done on 


line 
82 by sending 
the 
message 
back 
to 
the 
ex- 


change 
used for intertask 
lockout 
communications. 


The 
remainder 
of the program 
follows 
the flow- 


chart 
and 
the operations 
can be followed 
using a 


flowchart 
and the listing. Each element 
of the flow- 


chart corresponds 
to a block of code on the listing. 


CRT Update Task Development 


Earlier, 
we stated 
that the CRT update 
task would 


be used to allow the operator 
to view a "snapshot" 


of 
the 
four 
ovens. 
Let 
us turn 
our 
attention 
to 


developing 
the software 
which 
is required 
to ac- 


complish 
this. 
We can 
begin 
by defining 
the ele- 


ments 
which 
we feel 
should 
be displayed, 
then 


defining 
the 
format 
to actually 
be used 
with 
the 


CRT terminal. 


Obviously, 
we need to provide 
the current 
tempera- 
ture of each oven on our display 
screen. 
If we dis- 
play the actual 
temperature, 
it seems reasonable 
to 


assume 
that 
we should 
also show 
the set point 
so 


that 
a determination 
can be made 
as to how well 
the 
system 
is performing. 
The 
control 
algorithm 


has been defined 
to use an allowable 
range to deter- 


mine system 
outputs, 
so it would 
seen wise to also 


show this parameter. 
Finally, 
we should 
inform 
the 


viewer of the status 
of the oven so that he will real- 


ize that 
the reason 
an oven 
temperature 
is low is 


because 
the oven 
is off rather 
than 
an oven 
mal- 


function. 
Other 
items could 
be added 
if desired 
by 


the system 
designer, 
depending 
upon 
the total sys- 


tem 
requirements 
or 
the 
characteristics 
of 
the 


users. 


We can now prepare 
a drawing 
of the CRT display 


to generate 
a layout 
of our desired 
characters 
and 


to generate 
an aesthetic 
display 
for viewing during 


operation. 
This drawing 
can be found 
in Figure 33. 


Several 
techniques 
are available 
to output 
the re- 


quired 
displays 
to the terminal. 
A decision 
must be 


made as to the frequency 
of screen updates; 
will we 


constantly 
refresh 
the data 
or do it only at certain 


intervals 
of time? 
If the terminal 
has the ability 
to 


disable 
the cursor, 
it makes 
sense 
to update 
data 


continuously. 
If the cursor 
cannot 
be disabled, 
its 


movement 
tends 
to be distracting, 
so the updates 


should 
be kept to a minimum. 
The 
terminal 
used 


for 
the 
application 
note 
did 
not 
have 
a disable 


feature, 
so we will make 
the decision 
to only up- 


date 
the screen 
once each second. 


The 
decision 
to delay 
updates 
leads 
us to make 


another 
decision 
regarding 
the screen 
updates. 
If 


we only 
update 
a line which 
has data 
which 
has 


changed 
since 
the 
last 
update, 
the 
cursor 
move- 


ments will be kept at a minimum 
since it is unlikely 


that all parameters 
will ever change 
each second. 


A flowchart 
can now be prepared 
showing 
the steps 


required 
to implement 
the CRT 
update 
task. 
This 
flowchart 
is shown 
in Figure 34. The coding 
of the 


program 
to support 
this task can be found 
in Ap- 


pendix 
C. The 
development 
is identical 
with 
that 


which 
we described 
in the sections 
regarding 
the 


control 
task. 
Again, 
the software 
is divided 
into 
three parts, 
the declaration 
statements 
from lines 1 


to 81, the initialization 
on lines 82 to 87, and 
the 


actual 
task code on lines 88 to 207. 


A technique 
to exit 
from 
the CRT 
update 
mode 


and to get into a mode 
which will allow modifica- 


tion of the parameters 
has been introduced 
into the 
program 
and 
the 
display 
format. 
This 
is in the 


form 
of a message 
on the botton 
of the screen 
re- 


questing 
the entry of an escape character 
to adjust 


set points. 
The software 
has been written 
in such a 


manner 
as to test for a character 
inut from the key- 
board 
and 
if one 
is found 
corresponding 
to that 


character, 
the update 
task will allow the parameter 


update 
task 
to take control 
of the terminal 
(lines 


190 to 204 of the listing). 


Parameter 
Update Task 


The parameter 
update 
task is used to actually 
allow 


the modification 
of the setpoints 
and the tolerances 
associated 
with each oven. A second 
use of the task 
is to provide 
a tool for establishing 
the zero offset 
associated 
with each analog 
channel 
so that an off- 


set into the temperature 
linearization 
table can be 
computed 
by the control 
task. 


Figure 
35 shows 
the flowchart 
which describes 
the 
steps required 
to perform 
these operations. 
When 
the task has been completed, 
we will return 
to the 


CRT 
update 
task. 


The program 
code for this task can be found 
in Ap- 


pendix 
C and again 
follows 
the formats 
which 
we 
have discussed 
earlier. 
No attempt 
will be made 
in 


this document 
to provide 
a narrative 
of the listing 
since it follows 
the flowchart 
in development. 


Support 
Programs 


Three 
subprograms 
(procedures) 
have been written 


which provide 
functions 
which are common 
to the 
three tasks. This has been done to minimize 
repeat- 


ing code segments 
thus saving as much memory 
as 
possible. 
These 
three subprograms 
support: 


I. 
Conversion 
of a decimal 
string 
from 
the termi- 
nal into a binary 
number. 
This program 
is called 


ASC$2$BINARY 
and can be found 
in Appen- 


dix C. 


2. Storage 
for 
common 
variables 
used 
by more 


than one task. These variables 
could easily have 
been included 
in other 
tasks 
but a purely 
arbi- 


trary 
decision 
was made 
to include 
them 
in a 
separate 
module. 


3. Conversion 
of binary 
numbers 
into 
a decimal 


string 
suitable 
for output 
to the terminal. 
This 
program 
is called 
DEC$REP 
and 
is found 
in 


Appendix 
C. 


We now have completed 
the coding of the software 
to support 
our oven application. 
We must finish by 
combining 
all 
the 
software 
together 
to 
form 
a 
single loadable 
module. 


VI. FINAL IMPLEMENTATION 


When 
all code 
was linked 
and 
loaded 
to form 
an 
executable 
program 
module, 
it was found 
that 
the 
system 
required 
9,041 bytes of EPROM 
and 
1,735 


bytes of RAM. 
These 
values 
fall within 
our hard- 


ware capabilities 
and 
will rquire 
that 
we program 
and insert 
nine EPROMs 
into the EPROM 
expan- 


sion card. 


The system can now be tested and installed 
to con- 


trol the ovens of our application. 
The actual 
system 


described 
in this 
application 
note 
has 
been 
con- 


structed 
and 
tested. 
It has been 
found 
to control 


the oven temperatures 
of four ovens and performs 
as we anticipated 
when 
we developed 
our control 
strategy 
earlier 
in this application 
note. 


VII. CO 
CLUSION 


We 
have 
shown 
how 
Intel's 
single 
board 
com- 
puters, 
industrial 
chassis, 
termination 
panels, 
and 
software 
can be configured 
to provide 
a solution 
to 
a typical control 
application. 
We have seen how the 


development 
of a solution 
to a control 
problem 
can 


proceed 
along 
a predetermined 
and 
logical 
path. 


Truly, 
the utilization 
of the microprocessors 
can 


lead 
to optimum 
and 
cost 
effective 
solutions 
to 
control 
applications. 


APPENDIX 
A 
SELECTED DATA SHEETS 


TYPES Tll113. TIl119 


OPTO-COUPLERS 


• 
Gallium Arsenide Diode Infrared Source Optically 
Coupled 
to a Silicon N-P-N Darlington-Connected 
Phototransistor 


• 
High Direct-Current 
Transfer 
Ratic ... 
300% Minimum at 10 mA 


• 
Base Lead Provided for Conventional 
Transistor 
Biasing 


• 
High-Voltage Electrical 
Isolation ... 
1500-Volt 
Rating 


• 
Plastic Dual-in-Line 
Package 


• 
Typical Applications 
Include Remote Terminal 
Isolation, 
SCR and Triac Triggers, Mechanical Relays, and 
Pulse Transformers 


The 
package 
consists 
of 
a gallium 
arsenide 
infrared-emitting 
diode 
and 
an 
n-p-n 
silicon 
darlington-connected 


phototransistor 
mounted 
on a 6-lead frame encapsulated within 
an electrically 
nonconductive 
plastic compound. 
The 


case will 
withstand 
soldering 
temperature 
with 
no deformation 
and device performance 
characteristics 
remain stable 


when operated in high humidity 
conditions. 
Unit weight is approximately 
0.52 grams. 


'M"~~~ 
'"'''~'CJ 
,"'_.1 


000 


8. 
Leads 
are 
within 
0.005 
radius 
of 
true 
position 


(TPI 
8t 
the gauge 
plane 
with 
maximum 
material 


condition 
and unit 
installed. 


b. 
All 
dimensions 
are 
in 
inches 
unless 
otherwise 
noted. 


c. 
Pin 
1 
Identified 
by 
index 
dot. 
d. 
Terminal 
connections: 


1. 
Anode 
} 
Infrared.mittlng 
2. 
Cathode 
diode 


3. 
No 
internal 
connection 


4. 
Emitt.. 
} 


5. 
Collector 


6. 
Base (For 
TIL 
119, 
make 
Phototransistor 


no external 
connection) 
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absolute 
maximum 
ratings at 25°C free-air temperature 
(unless otherwise 
noted) 


Input-to-Output 
Voltage 
..... 


Collector-Base Voltage (TI L 113) 
. 
. 
. 


Collector-Emitter 
Voltage (See Note 1) 


Emitter-Collector 
Voltage 


Emitter-Base Voltage (TI L 113) . 


Input-Diode 
Reverse Voltage 


Input-Diode 
Continuous 
Forward Current at (or below) 25°C Free-Air Temperature 
(See Note 2) 
Continuous 
Power Dissipation 
at (or below) 25°C Free-Air Temperature: 


Infrared-Emitting 
Diode 
(See Note 
3) 
..... 


Photo transistor 
(See Note 4) 
. 
. 
. 
. 
. 


Total 
(Infrared-Emitting 
Diode 
plus Phototransistor. 
See Note 
5) 


Storage Temperature 
Range 
Lead Temperature 
1/16 Inch from Case for 10 Seconds 


±1.5kV 


30 V 


30 V 


7V 
7V 


3V 


100mA 


150mW 
1:;0 mW 


250 mW 
-55°C 
to 150°C 


260°C 


NOTES: 
1. 
This value 
applies 
when 
the base-emitter 
diode 
is open-circuited. 
2. 
Derate linearly to lOOoe free-air temperature 
at the rate of 1.33 mA/C. 


3. 
Derate 
linearly 
to lOOoe free-air 
temperature 
at the rate of 2 mW/oC. 


4. 
Derate 
linearly 
to lOOoe free-air 
temperature 
at the rate of 2 mWf'C. 


5. 
Derate 
linearly 
to lOOoe 
free-air 
temperature 
at the 
rate of 
3.33 mW/oC. 


TEXAS 
INSTRUMENTS 
INCORPORATED 


POST 
OFFICE 
BOX 
5012 
• 
DALLAS, 
TEXAS 
75222 


TYPES 
TIL113. TIL119 


OPTO-COUPLERS 


TEST CONDITIONS' 


TIL113 
TIL119 
PARAMETER 
UNIT 


MIN 
TYP 
MAX 
MIN 
TYP 
MAX 


Collector-Base 


VIBRICBO 
IC'lO)lA, 
IE' 
0, 
IF' 
0 
30 
V 


Breakdown 
Voltage 


Collector-Emitter 
VIBRICEO 
IC'l 
mA, 
IB ' 0, 
IF' 
0 
30 
30 
V 


Breakdown 
Voltage 


Emitter-Base 
VIBRIEBO 
IE'lO)lA, 
IC = 0, 
IF = 0 
7 
V 
Breakdown 
Voltage 


Emitter·Collector 
VIBRIECO 
IE = 10 )lA, 
IF' 
0 
7 
V 


Breakdown 
Voltage 


On-State 
VCE = I V, 
IB = 0, 
IF = 10 mA 
30 
100 
IClonl 
mA 


Collector 
Current 
VCE - 2 V, 
IF = 10 mA 
30 
160 


Off·5lale 


ICloffl 
VCE = 10V, 
IB = 0, 
IF' 
0 
100 
100 
nA 
Collector 
Current 


Transistor 
Static 


hFE 
Forward 
Current 
VCE = I V, 
Ic=10mA, 
IF' 
0 
15,000 


Transfer 
Ratio 


VF 
1nput 
Diode 
Static 


IF = 10 mA 
1.5 
1.5 
V 


Forward Voltage 


Collector-Emitter 
IC-125mA, 
IB - 0, 
IF - 50mA 
I 


VCEI,al) 
V 
Saturation 
Voltage 
IC- 
10mA, 
IF-l0mA 
I 


Input-le-Output 
Vin-out 
= ± 1.5 kV, See Note 6 
lO" 
lOll 
n 
'10 
Internal 
Resistance 


Cio 
1nput-ta-Output 


Vin-out = 0, 
f = I MHz, 
See Note 6 
1.3 
1 
1.3 
pF 
I 


Capacitance 


NOTE 6: 
These parameters 
are measured between both input-diode 
leads shorted 
together 
and all the phototransistor 
leads shorted 
together. 


t References 
to the base are not applicable 
to the T I L 119. 


TIL113 
TIL 119 
PARAMETER 
TEST CONDITIONS 
UNIT 


MIN 
TYP 
MAX 
MIN 
TlfP 
MAX 


I, 
Rise Time 
VCC - 15 V, 
IClonl 
- 125 mA, 
50 


If 
Fall Time 
RL"00n, 
See Figure 1 
50 
)l' 


I, 
Rise Time 
VCC 
10 V, 
IClon) - 2.5 mA, 
50 


If 
Fall Time 
RL=100n, 
See Figure 1 
50 
)l' 


1-- 
J I 
IollI 


I 
// 


I 


I 
I 
- L_ 


PARAMETER 
MEASUREMENT 
INFORMATION 
l47n 


VYV----OINPUT 
I 
I 
I 
I 
~ 


Adjust amplitude 
of input pulse for: 


IClonl 
= 125mA 
ITIL1131 


IClonl 
' 2.5 mA ITI L 119). 


NOTES: 
a. 
The 
input 
waveform 
is supplied 
by 
a generator 
with 
the 
following 
characteristics: 
Zout 
= 50 n, tr c; 15 ns, duty 
cycle 
~ 1%, 


tw'" 
lOa 
/-is. 


b. 
The output 
waveform 
IS monitored 
on an oscilloscope 
with 
the following 
characteristics: 
tr ~ 12 ns, Rin ;;. 1 Mn, 
Cin ..,;;;20 pF. 


TEXAS 
INSTRUMENTS 


INCORPORATED 


POST 
OFFICE 
BOX 
5012 
• 
OALLAS. 
TEXAS 
75222 


TYPES 
TIL113, TIL119 


OPTO-COUPLERS 


<t 
E.!. 
80 
c: 
~ 
::>U 
60 
j 
"0 40 
u 
I~ 


400 


<t 
200 


E.!. 
c:., 
100 
~u 
70 
~ 
~ 
.!!l 
"0 
40 
u 
I~ 


20 


TlLl13 


COLLECTOR 
CURRENT 


vs 


COLLECTOR·EMITTER 
VOLTAGE 


TlLl19 


COLLECTOR 
CURRENT 
vs 


COLLECTOR·EMITTER 
VOLTAGE 


200 


180 


160 
<t 
E 
140 
.!. 
c: 
~ 
120 


::> 
IF ~ 50 mA 
U 
100 
0 
tJ 


..•. ..•. 
.!!l 
80 


"0u 
60 
I~ 
40 
IB ~ 0 


20 
TA ~ 25°C 


See Note 
7 


0 


0 
0.2 
0.4 
0.6 
0.8 
1.2 
1.4 
1.6 
1.8 
2 


VCE-Coliector·Emitter 
VOltage-V 


FIGURE 3 


OFF-STATE 
COLLECTOR 
CURRENT 
vs 


FREE-AIR 
TEMPERATURE 


1000 


<t 
VCE ~ 10 V 
1 
100 
IB ~ 0 


c 
IF ~ 0 
~:;u 
10 
~ 
~ 
.!!l 
"0u~ 
'"~ 
0.1 
0 
I 
~ 
0.01 
.£ 
u 


0.001 


0 
25 
50 
75 
100 
125 


T A-Free-Air 
Temperature- 
°c 


FIGURE 5 


IB ~ 0 


TA 
~ 25°C 
100 
See Note 7 


TILl13 


COLLECTOR 
CURRENT 


VCE ~ 1 V 


IB ~O 


TA 
~ 25°C 


/ - 
/ 


1/ 
I 
/ 
1/ 
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TEXAS INSTRUMENTS 


INCORPORATED 


POST 
OFI"ICE 
BOX 
5012 
• 
DALLAS, 
TEXAS 
75222 


TYPES 
TlL113. TIL119 


OPTO-COUPLERS 
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•... 


.~ : 
E ~ 
":'> 
B B 
u 
Cll 
~ 
> 
8~ 
I 
Cll 
~a: 
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T1L 113 


RELATIVE 
COLLECTOR-EMITTER 


SATURATION 
VOLTAGE 


vs 


FREE·AIR 
TEMPE;RATURE 


T1L113 


TRANSISTOR 
STATIC 
FORWARD 


CURRENT 
TRANSFER 
RATIO 


vs 


COLLECTOR 
CURRENT 


, 
"'" 
VCE = 1 V 


t-IF=O 


I-- T A = 25°C 
\ 


V 
\ 
I-- 
- 


~ 
I-- 
- 
- 


I-- 
- 
I-- 
- 
- 
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I-- 
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- 
- 
I-- 
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- 
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- 
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IC = 125 mA 


I-- IB=O 


IF = 50 mA 


r------- 
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u 
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Iw 
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INPUT 
DIODE 
FORWARD 


CONDUCTION 
CHARACTERISTICS 


<t: 
E 


~ 
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o 
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0.2 
04 
0.6 
0.8 
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VF-Forward 
Voltage-V 


FIGURE 8 


TEXAS 
INSTRUMENTS 
INCORPORATED 


PfillNHO IN USA 


t: 
lanna' 
anumr 
any 
rnpon1,b,I,ly 
lor 
on, 
("(II'" 
shown 


or 
rrprrlrnl 
'har 
!hlt 
Off 
fltf 
from 
poltnl 
,nf,in9tmtnt 


I/O Module Detail 
Electrical Specifications 


ACINPUT 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
DC INPUT 
MODEL 
MODEL 
MODEL 
MODULES 
lACS 
IACIS 
IAC24 
IACS·A 
IAC1S·A 
IAC24·A 
MODULES 
IDCS 
IDC1S 
IDC24 


AC INPUT 
LINE 
95 to 
180to 
INPUT 
LINE 
10-32 
VDC 
VOLTAGE 
130 VAC 
280 VAC 
VOLTAGE 


INPUT 
CURRENT 
10ma 
INPUT 
CURRENT 
32 ma at 32V 
AT RATED 
LINE 


ISOLATION 
2500 
Volt 
RMS 
ISOLATION 
INPUT 
2500 
Volt 
RMS 
INPUT 
TO OUTPUT 
TO OUTPUT 


INPUT 
ALLOWED 
1.5 ma 
CAPACITANCE 
8P1 
FOR 
NO OUTPUT 
INPUT 
TO OUTPUT 


TURN 
ON TIME 
20 Millisecond 
Maximum 
INPUT 
ALLOWED 
2 ma 
FOR NO OUTPUT 


TURN 
OFF 
TIME 
20 Millisecond 
Maximum 
TURN 
ON TIME 
5 Millisecond 
Max 


OUTPUT 
TRANST. 
30 Volts 
DC 
TURN 
OFF TIME 
5 Millisecond 
Max 
BREAKDOWN 


OUTPUT 
CURRENT 
25 ma 
OUTPUT 
TRANST. 
30 Volts 
DC 
BREAKDOWN 


OUTPUT 
LEAKAGE 
100 Microamp 
Maximum 
OUTPUT 
CURRENT 
25 ma 
30VDC, 
NO. 
INPUT 


OUTPUT 
VOLTAGE 
.4 Volts 
at 25 ma Load 
OUTPUT 
LEAKAGE 
100 Microamps 
Max 
DROP 
30 VDC 
NO INPUT 


LOGIC 
SUPPLY 
4.5to 
12 to 
20 to 
4.5 to 
12 to 
20 to 
OUTPUT 
VOLTAGE 
.4 Volt at 25 ma 
VOLTAGE 
DC 
6V 
18 V 
30V 
6V 
18 V 
30 V 
DROP 


LOGIC 
SUPPLY 
12ma 
15 ma 
18 ma 
12 ma 
15 ma 
18 ma 
LOGIC 
SUPPLY 
4.5 to 
12 to 
20 to 
CURRENT 
VOLTAGE 
6V 
18V 
30V 


LOGIC 
SUPPLY 
12 ma 
15 ma 
18 ma 
AC OUTPUT 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
MODEL 
CURRENT 


MODULES 
OACS 
OACIS 
OAC24 
OACS·A 
OAC1S·A 
OAC24·A 


LINE 
VOLTAGE 
12 to 
24 to 
DC OUTPUT 
MODEL 
MODEL 
MODEL 


140 VAC 
280 VAC 
MODULES 
ODCS 
ODC1S 
ODC24 


CURRENT 
RATING 
3 AmpsG) 
LOAD 
VOLTAGE 
60V 


RATING 
DC 


I·CYCLE 
SURGE 
55 Amps 
Peak 
OUTPUT 
CURRENT 
3 A 
G) 


RATING 
mps 


SIGNAL 
INPUT 
220 
lK 
2.2K 
220 
lK 
2.2K 
OFF 
STATE 


RESISTANCE 
Ohm 
Ohm 
Ohm 
Ohm 
Ohm 
Ohm 
LEAKAGE 
1 ma Max 


SIGNAL 
PICKUP 
3V 
9V 
18V 
3V 
9V 
18V 
ISOLATION 


VOLTS 
DC 
8V Aid: 
16V Ald.· 
32V 
Aid: 
8V Aid: 
16V Aid: 
32V Ald.· 
INPUT 
TO OUTPUT 
2500 
V RMS 


SIGNAL 
DROPOUT 
1 Volt 
SIGNAL 
PICK 
UP 
3V 
9V 
18V 
VOLTS 
DC 
VOLTAGE 
8V Aid: 
18VAld: 
28V Aid: 


PEAK 
REPETITIVE 
400V 
500 Volts 
SIGNAL 
DROP 


VOLTAGE 
OUT 
VOLTAGE 
1Volt 


MAXIMUM 
1.6V 
SIGNAL 
INPUT 
220 
lK 
2.2K 
CONTACT 
DROP 
RESISTANCE 
Ohm 
Ohm 
Ohm 
OFF 
STATE 
5maRMS 
LEAKAGE 
1 SECOND 
SURGE 
5 Amps 


MINIMUM 
20 ma 
LOAD 
CURRENT 
TURN 
ON TIME 
500 Microseccnd 


ISOLATION 
2500 
Volts 
RMS 
INPUT 
TO OUTPUT 
TURN 
OFF TIME 
2.5 Milliseccnd 


CAPACITANCE 
8P1 
• Allowed 
INPUT 
TO OUTPUT 
G)Derate 
.033 Amps 
per degree 
C from 
200 C 


STATIC 
200 Volts/Microsecond 
Min 
DV/DT 


COMMUTATING 
Built in snubber 
(will commutate 
DV/DT 
.5 power 
factor 
loads) 


'Allowed 
_-..L_ 
iii5iliir.-F" 
~~~~ 
=== 


High Voltage DC Output Modules 
Fast Switching DC Input Modules 


DC OUTPUT 
MODEL 
MODEL 
MODEL 
DC INPUT 
MODEL 
MODEL 
MODEL 
MODULES 
ODC5-A 
ODC15-A 
ODC24-A 
MODULES 
IDC5-B 
IDC15-B 
IDC24·B 


LOAD 
VOLTAGE 
200V 
INPUT 
LINE 
4-16 
VDC 
RATING 
DC 
VOLTAGE 


OUTPUT 
CURRENT 
1 Amps 
INPUT 
CURRENT 
.14 ma at5V 
RATING 


OFF 
STATE 
2 ma Max 
ISOLATION 
INPUT 
2500 
Volt RMS 
LEAKAGE 
TO OUTPUT 


ISOLATION 
2500 
V RMS 
CAPACITANCE 
8pt 
INPUT 
TO OUTPUT 
INPUT 
TO OUTPUT 


SIGNAL 
PICK 
UP 
3V 
9V 
18V 
INPUT 
ALLOWED 
1 Volt 
VOLTAGE 
8VAld: 
18VAld: 
28V Aid: 
FOR 
NO OUTPUT 


SIGNAL 
DROP 
1Volt 
TURN 
ON TIME 
50 Microsecond 
Max 
OUT 
VOLTAGE 


SIGNAL 
INPUT 
220 
1K 
2.2K 
TURN 
OFF 
TIME 
100 Microsecond 
Max 
RESISTANCE 
Ohm 
Ohm 
Ohm 


1 SECOND 
SURGE 
5 Amps 
OUT 
TRANSISTOR 
30 Volts 
DC 
BREAKDOWN 


TURN 
ON TIME 
500 Microsecond 
OUTPUT 
CURRENT 
25 ma 


TURN 
OFF 
TIME 
2.5 Millisecond 
OUTPUT 
LEAKAGE 
100 Microamps 
Max 
30 VDC 
NO INPUT 


·Allowed 
OUTPUT 
VOLTAGE 
.4 Volt at 25 ma 
DROP 


LOGIC 
SUPPLY 
4.5 to 
12 to 
20 to 
VOLTAGE 
6V 
18V 
30V 


LOGIC 
SUPPLY 
12ma 
CURRENT 
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APPENDIX 
C 
PROGRAM 
SOURCE 
LISTINGS 


STITLE 
('CONTROL 
TASK') 
/***************************************************** 
* 
This 
task 
han~les 
the 
r.:ontrol 
imc 
monit.oring 
of 
.• 


* 
four 
oven 
chAmb~rs. 
* 


*****************************************************/ 
CCN~ROLST~SKrMODULE: 
Do· 
OECLJI.RE P.XCH1'NGE$DFSCRT PTCn 
L TTBRALLY 
I S'l'HlJC'lUHE( 


MESSAGE$HEAO 
ADDRESS, 
MESSAGEtTAIL 
ADDRESS, 
TASK$hEAD 
ADDRESS, 


TAS~$ThIL 
~nDRESS, 
EXCHANGE$LINK 
ADDRESS) 
'; 
DECL,lI,RFTRUE 
LI'1'E(;ALLY'01'FI1 '; 
DECLARE 
FALSE 
LITERALLY 
'C0H'; 


DECLARE 
BOOLEAN 
LITERALLY 
'BYTE'; 
DECLARE 
FOREVER 
LITERALLY 
'WYILE 
J '; 


DECLl'RE "'ISG$HDH LJTEllALLY 
, 
LINK 
ADDRESS, 
LRNGTH 
ADDRESS, 


'l'YPEBYTE, 
HCMESEX 
ADDRESS, 
RESP$EX 
ADDR£SS'; 


DECLARE 
MSGSDESrRJPTOR 
LITERALLY 
'STRUCTUHE( 


IYlSG$HDR, 
HEMAINDER(l) 
BYTE)'; 


/* 
,lIIMSG.ELT - ANALOG 
INPUT 
REQUEST 
MESSAGE 
FORMAT 
*/ 
DECLARE 
Ar~FG 
LlTERALLY 
'STRUCTURE( 
MSG$HDR, 
S1'lITUS 
I\DDRFf'S, 
BASE$PTR 
ADDRESS, 
CH~NNEL$GATN 
ADDRESS, 
ARRAY$PTR 
ADDRESS, 
COUN'l' 
l\DDHESS, 
ACTUAL$COUNT 
ADDRESS) 
'; 


/* AITYP.ELT 
- lNALOG 
INPU~ 
MESSAGE 
TYPES 
*/ 
D~CLARE 
AIREP 
LITERALLY 
'3~1, 


AISQS 
LITERALLY 
'3] " 
AISQV 
LITERALLY 
'32', 
ATRAN 
LITERALLY 
I~~I; 
Declare 
(n,k) 
bytE'; 


D(c]are 
(~SG~PTR,LOCKOUT) 
~ddress; 
DecJ£ra 
(BLOCKC,BLOCKl,BLOCK2,BLOCK3) 
byte 
external; 
Declar~ 
TOLERANCE(4) 
bddress 
external; 


D0clare 
TEMP(4) 
ndrlress ext~rna]; 


Df·cli:,reSETPOIN'.I'(4) ,c,rlnressextern,'l; 
Derl?re 
T$AVERAG~(4) 
address; 


necli:1r~ T$LAST(4) 
eddress; 
Derlare 
TSLAST$AVERAGE(~) 
ad~ress; 


D"':],He 
T~·t5(1!) 
i'ddress; 


D~c]are 
T$tlr(t) 
~ddress; 


Dec~are 
STATUS(4} 
byte 
cxternnl; 


Declare 
CRT$DISPLAY$LOCK(S) 
address 
external; 


211 
] 
25 
1 
2(; 
1 


2'"' 
1 
. ' 
21' 
1 
29 
J 


30 
J 


3J 
1 


~2 
1 


33 


3,~ 


35 
:' 


30 
~ 


J7 
1 


~8 
2 
39 
2 


40 
1 


11 ] 
? 
~2 
2 


~ 
"l 
1 


44 
1 


~5 
1 


tit) 


47 


48 


t.9 
J 
sr 
1 


DecL:ac 
TEt>1PS(,ALIBIi~1'E(S) (~(1cl)l'SS"xt.(,~rn(;lio 


Declare 
DUM~Y$~xrH(5) 
address 
externali 


Dprlare 
TF~p$LCrKOUTSfXrf!(5) 
~~dless 
extern~li 
Declare 
RQAIEX(5) 
Dcldress 
ext0rn~li 


D~clnre 
Atn~EXCH(5) 
address 
externali 


Declare 
CONSTANT$LOCKOUT~EXCH(5) 
Dddress 
extern~l; 
Der.lare 
rH'f$S'l'A'IU~;$EXCH(~»),c.(je'ress,'xternilJ.i 
Declare 
ALAR~$MSG 
structure 
(MSG~HDR); 


Declare 
CONVERT 
piSms0i 


/* 
Thi.s term 
is 
used 
to 
cOllvey 
init'ial 
j-.emperntures 
*/ 


Declar~ 
CAL¢TEMP 
b?sed 
MSG$PTR 
structure 
( 
MSGSHDR, 
CAL 
?ddress 
) i 


R Q\·v A I'I' : 


Procec1ure 
(ExrH,ME:~f;AGE) 
~ddless 
~~tC(n2~; 


Declar·? 
(E:XCfI,MESSAGE) 
?d(1reSSi 


end 
R('\A'lI.rT 
i 


RQSEND: 


Proce~ure 
(~xrH,MESSAGP) 
externali 


Declar" 
(EXCH,I"iESSACE) 
o(1dreSSi 


end 
R(lSE:~D; 


RQACP1': 
Pror.edure 
(EXCH) 
?ddr~ss 
ext0rn2]; 


De~lare 
EXCH 
i1d~ress; 


(~n(1 
r,QACP'l'i 
npC]Arr 
OVEN~IN$TOL(~) 
byte 
d~tA 
~ 


PIH,P2H,etH,08H 
)i 


Declare 
OVEN$CAUTION(4) 
byte 
~at~ 
( 
]0H,2rH,(rH,prH 
); 


Dp~lace 
OVENSDANGER(4) 
byte 
~ata 
( 


0.lli,1'2J-l,0lJH,GQH 
)i 


De~]are 
OVENSONSMASK(~) 
byte 
~at? 
( 
01H,(j2Ij,('~H,(1Erl 
); 


Vecl~re 
CVENSHEATER(4) 
byte'datA 
]rIi,?0H,llrH,Q0Fi 
)i 


Dec]~r~ 
OVEN$RUN(n) 
byte 
~atr 


lrp,20H,~VH,nrH 
); 
De~lAre 
OFFSE~(~) 
~ddressi 


Declare 
1AHLE(255) 
iddress 
d~tri 
( 


200,2rl,207,201,2C~,2r5,2P~,2U7,2~~,209, 
2(19, 
7] r , 2) ] ,21 2, 213, 
21 ~ , ;') 5 ,2] 
h, 21 7 , 2 J f' , 
~JS,22V,22],222,223,2211,225,7.?~,227,2?8, 
220,22(,,231,2:12,2<3, 
-:>J5, 7?r;, 
27,;7, 2:'lP, r's, 


2~~,2~l,2t2,2~t,24S,2t7,2t;Q,2t,9,7.SC,25J, 
21:'.2, 
?C:;I1, 2S", 2S"},2<;8,2C;9, 
2(-if,;:;-;1,7<;3,2"5, 
26~,2r;7,2r.;8,269,27P,~7],27~,274,276,27R, 
27?,2r.!<,282,2f'11,285,?P7,2I'C,2RC 
,2S'r,2C'1, 


::> 9 ? , 2,} <; , 2 91i 
, 7.<) D, 299 , ::1.('r, , 
0) c; 2, : ('4 , 3 r. 5 , 'C 7 , 


3 r 
Q 
, ? c:s: , ? 10 , 31 2 , ~ 1~ , .3] <; , 
~ U? , 37.'" , :' 2? , :' 2 t, , 


:26,328,?3r,JJ2,~JlJ,3JIi,JJ8,34r,~t2,3"'~, 


~ 
i1 (~ I :. It R , ? 5 r. , ? 5 2 I -:)5 ~ , :-'5 ~ , ~.5 r' , ~ (; (.1 , 3 () 2 , .? () 
j1 
, 


36~,JS8,J7P,J7?,?74,~7G,~7P,J80,3P2,38S, 
~nr,?~t(1,3~2,39~,:Q0,t("r,tr',~'·5,~(··I/~1':, 
t. ] '2 , I- ] ~ , 
~ ] I': , I' 2 r , I' /.:' 
, 
.~ 2 r; , I' 2 R , ,,: r,, I' ~:. 
, il :;:() , 


~]9,nA] 
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,45t,~~?~~~r 
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2 


6C 
-; 


G) 
.' 


(;2 
") 


M~ 
3 


(';1' 
3 


'"c: 
~ 
-)., 


r:.r 
:3 
.) '.J 
(i" 
, 
) ! 


f)~ 
4 
~ 
/ ~ 
) 
4 


71 
5 


72 
5 
'n 
t1 
71: 
5 


75 
5 
7F. 
,1 


77 
::- 


78 
I' 


f(' 
/. 


Q' 
I' 
.•• 
.J. 


82 
., 


~7r,~?J,~7~,~~(-,'~1,~C8,~ 
7,~9~/~rf,~( 
I~, 


5 i '1 , 51 1 , 
r::, 1 ') , t.; l ') , '. 2 '; , 
<: 2 ~ ,c: 
1., 5:; 5 , ~t. C , ~ 11 5 , 


55r,~~5,5~r,5G~/~70,!;7S,5 
r,5r5,~sr,sc'5, 


r; n r. , G~~~',, r, t C 
t r, 1 5 , ~2 C , ()? 5 , r: J f' , r; ~ 5 , r.:" r , ~" 5 I 


h5r,G55,6~0,('~5,~70,~75,6BF,~R5,G9C,~95, 
7 I' r , '7 Cr) , 7 J f' , 7 J 5 , 7 L r , 7 /. 5 , 7" V, 7:,5 
, -;f; r , ./4 ~,, 
75r,0cr,~~c,rfr,n0r,CAr,rrr,0rF,vrr,AA0, 
001',rrr,rrr,rrr,rrr,er~,rcr,rrr,r,,~,rr0, 
orr,err,C00,per,000,rrr,far,nrr,rV0,rr0, 
e('n,r0r.rr0,cN·,r('v:,('rr~ 
); 


/~ 
Jnitiallz2tion 
of 
control 
task 
*/ 


CON't'RCJLSTASK: 
Pror.efur~ 
puhlici 


Output(235)=DJHi 
CONVERT.BASE$PTR=£F70rHi 
CONVERT.[ENCTH=21i 
CONVERT.TYPE=AISCSi 
CONVER~.R~SP~8x=.aSD$EXCHi 
CONVERT.CHANNELSGPTN=r; 
CnNVER'l'. 
AlHtll Y$PTH=. 
'l'Er'lP; 
CONVER'I'. 
COUNT=!; ; 


Do 
f: 0 l ~;" c' I i 


/- 
~?it 
for 
one 
secon~ 
to 
tldpse 
~/ 


~SGtPTR=Rr~AIT 
(.DU~NY~EXCH,7r); 


/~ 
Bring 
in 
(~Fti1 
from 
swilch,'s 
-/ 
BLOCK0=N0T 
INPUTI2JI); 


/~ 
Lockout 
tpmpEf(;l:ure 
storAge 
2rces 
for 
upc1. te 
*1 


LUCKOlJ'l'=HQ\,\'1 
IT 
(. TEi"IP$LCC!<'('U'i'$EXCH, 
C-) 
; 


I~ 
Get: 
r&w 
~sta 
from 
nn~loy 
conv~rter 
~I 


Cnl] 
ROSEND 
I.RQAIEX,.CDNVERT)i 


N]S(~ SPTR=ROW/'.JT 
(. i\~[)$EXCH, 
(.;) ; 


/- 
'TeWpt'lilturo;! 
C?Ji':1ri·te 
PIO~tcJlIL" 
*1 
MSG~PTR=ROACPT(.TEMP$CALIBRi\TE); 


T f 
M~~G$P'I'R 
<> 
() 


then 
00; 
!i.=('i 
Do 
~hj's 
ITABL~(~)<>CALTEMP.CAL 
AND 


k<255) 
; 


k=I-;+I; 
f'nc; 
Do 
n=f1 
to 
~ i 
OFFSET(n)=(TEMPln)/15)-k; 


f' n(l; 


enc.i 


1* Convert 
('ate 
into 
engin,~ering 
units 
-/ 
Do 
n=f1 
1:0 J; 
lf 
«(TEMr(n)/]~)-OFf~E1(n)))255 
then 
TEMP (n) =r'; 


~ls0 TEMP(n:=TABLE«(TEMP(n)/]G)-0fFSET(n))i 
l~nc) ; 


i* 
Releisr 
lockout 
of 
tpmrer2tures 
*/ 


C2'1 
RQSEND 
(.TE~P~LOCKOUTSEXCH,L(CKOUT); 


/* Compute 
av~r2g~ 
tcm~0rrl:urE 
*/ 


fP 
3 
, .. 
81.\ 
" 


e~ 
" 


117 
r. 
.J 


88 
c. 


89 
5 
9(' 
t, 


91 
r:, 


92 
5 


93 
5 


9i\ 
It 
9S 
1.\ 


9(, 
L! 


97 
" 


SC; 
5 
1r(: 
5 


HI 
5 


11':< 
Fi 


.104 
t- 
105 
r; 


l~e; 
5 


H7 
S 


H9 
IS 


1 1 r 
r- 


]1.1 
r, 


lP 
:.' 


11.1 
'3 


115 
r; 
111) 
I'i 


1) 7 
I) 
IH 
c; 


P9 
~ 


12~ 
5 


1 ?7. 
5 


] 
;:> ~ 
'1 


PI; 
5 
] 25 
5 
126 
5 


Do 
n=0 
to 
1; 
T£AVFHAGE(n)=(T$LAfT(n:+~EMP(n:\/2; 
1- 
Projer.t 
tempe ri"tUtes 
into 
th:~ 
future 
*1 


if 
T$AVEHAGE(n)~=TSLASTSAVERAG~(n) 
Uwn 
do; 
TetS(n)=(T$AVrRAG~(nl-T$LPST$AVERAGE(n))*51 


+T$LASTSAVERAGE(n); 
T$tJe(n)=«(TSAVERAGE(n)-TSLAST~AVERACE(n))*JP) 


+T$LAST~AVERAGE(n); 


r: nt1 ; 
21se 
do; 
TSt5(n)=TtLASTSAVER~GE(n)-«TSLASTSAVERAGE(n) 


-TSAVERAGE(n))*S); 
T $ t ] v, (n) =TSLASTS/' VE RAGE ( n) - ((T $Ll' s'r SIIVEH/\CE 
(n) 


-TSAVERAGE(n))*]C); 
end; 
1- 
Up~~te 
stored 
~ata 
-I 
TSL~STS~VERAGE(n)=TtAVERAGE(n); 
T$LAST(n)=TEMP(n); 


1* Test 
for 
~~tive 
oven 
*1 


MSG$PTR=RQWAIT 
(.CONSTANT$LOCKOUT$EXCH,P); 
IE 
«((PLaCKO 
AND 
OVENSUNSMASK(n))<>0) 


AND 
(TE1V\P(nIOr)) 
then 
(~o; 
~JTA'rUS (n) =7; 
RLOCK2=eLnCK~ 
OR 
nVCN$RUN(n); 
1* 
Test 
for 
2n 
intolerAnce 
~on0ition 
~I 


If 
S£TPOTNT(n)-TOLERPNCE(nl 
< 
T~MP(n) 
PND 


SE'I'POINT (n)+'l'OLERI\NCE(n) 
> 
TEMP(n) 


then 
(~o; 
STA'l'US 
(n) 
=7; 
BLOCK1=bLOCKl 
nn 
OVENSINSTOL(n); 


efl~i 
c)St 
BLOCIO=BLOCKl 
AND 
NOT 
OVE;NSH1~TOL(n); 


1* 
Test 
for 
0 
cilut-ion conC!ition 
*1 
If 
SF'] 
POINT 
(n)_rl'OLF.HANCE 
(n) 
> 
TSt5(rl) 
OR 


SETPOINT(n)+TOLERANCE(n) 
< T$t5(n) 


t0f:n 
<10; 
S T ,11,'1' U S ( n) =] 4 ; 
BLOCKJ=RLOC'KJ 
i)H 
l:VENsel,U'l'lON(n) ; 


€:T\C1; 
elSt, 
E:LnCK'=l'.LOCKI 
AND 
rJOT 
OVF:NSCl\lf'i'll'N(n); 


1- 
Test 
for 
? 
frng~r 
con~i~ion 
~I 
If 
~)~TP(jIN'l'(n)-'rOlfHflNCL(n) 
> 
1El"iP(n) 
CH 


SETPOINT(n)+TOLERANCE(n) 
< 
TEMP(n) 


~h~~n (10; 
S'l'NfUS (n) =2] ; 
BLQCK7=ELOCK7 
0H 
UVEN$DANGEkln); 
enr] 
; 


eJs~ 
RLOCK7=PLOCK7 
AND 
NO~ 
OVEWSOANGER(n); 
1- 
H?nfle 
contro] 
of 
hC2t~r 
~lements 
*1 


If 
S~TPCIN7(nl 
> 
-rStJ0(n) 
then 
BLOCK3=RLOO:': 
OR OVENSHEATER(n); 


c 1 S0 
bLOCK 
C'=E' LOCJ~' 
AND 
NOT 
OVENSHEA'j'ER 
(nl ; 
en0; 


else 
do; 
/* 
Turn 
everything 
off 
whr'n 
operator 
shuts 
off 
ov()n 
*1 


BLOCX)=RLOCKI 
AND 
NnT 
CVEN$IN$TOL(n); 


BLOC!:] =I3U;('I\J 
AND 
NOT 
UVE:--J$CAUTION(n) ; 


BLOCK3=RLOCK~ 
AND 
NOT 
OVEN$HCATER(n)i 


3·42 
AFN-Q1931A 


127 
:-; 


1/.8 
5 


129 
5 
ur 
c; 
131 
~ 


132 
il 


P3 
3 
IV 
'I 


135 
~ 


1~11 
~ 
.~ 


137 
2 


I? 11 
1 


BLOCK2=BLOCK2 
A~D 
NOT 
OVEN$DANG£R(n); 
BLOCK2=BLOCK2 
AND 
NOT 
OVEN$HUN(n); 


:::TlI.'l'U~;(n)=V; 


end; 
Call 
R('~;EN[) 
( .cONf'T}\N1'~LOC!<OU'l'$EXCB,folSG$P'l H) ; 


enC'; 


/* Output 
d2t2 
to real 
world 
*/ 


OUTPUT(7~7)=BLOCKl; 
OU~PUT(233)=ELOCK2; 
OUTPUT(234)=RLOCK?; 


enc; 
end 
CONTROL$TASK; 


end 
C0NTR0L$TASK$MCDUL~; 


CODE 
AIlEA 
SIZE 
VAlUABLE 
ArlE/\ S IZi': 


MI\XTJ'1t:M 
STACK 
SIZE 
235 
LINES 
HEllO 
{; 
Pl1CGRI\JoII ERIWH 
(S' 


r. 9 4 "II 
0f'548 
0HI1H 


237..'1D 
rilD 


fiD 


;'l'I'fLf. ( 'CH'J' 
P!d~AME'i'£F; 
'l'ASI<') 


/********************************************** 
* 
'rids 
t?sk 
is 
lJS(~(] 
to 
,-'xnmint> 
,mel 
update 
the 
* 


* 
~pmp~IatU(~ 
setpoints 
an~ 
toJel~n~es 
for 
* 
* 
ec:ch 
0 E 
the 
four 
ovcns. 
* 


**********************************************/ 
UP 1),1 T \: t'I'AS J(: 
Do; 


SInclude 
(:FV:COI'i/>lCN.EL'l') 
DECLARE 
TRUE 
LITERALLY 
'~FFH'; 
DECLARE 
~ALSE 
LITERtLLY 
'r0H'; 
DECLARE 
BOOLBAN 
LITEHALLY 
'bYTE'; 


DECL!\RF 
FCREVER 
L1TI::RP.,LLY'''''III 
LE 
1'; 


tlnclude 
(:F0:MSGTYP.ELT) 


DECLARE 
DATf$TYP£ 
LIT~RALLY 
'f', 
INTSTYPP. 
LITERALLY 
'I', 
~ISSEDSINT~TYPE 
LITERALLY 
'2', 
TIMESOUT~TYPE 
LITERALLY 
'3', 
FSSREQ~TYPE 
LITERALLY 
'~', 
UC$REQS~YPE 
LITERALLY'S', 
FS~N~KrTYPE 
LITERALLY 
'6', 
CNTRL$C$TYPE 
LITERA~LY 
'7', 
READSTYPF 
LITERALLY 
'8', 
CLRSRD$TYPE 
LrTERALLY 
'9', 
L,1\S'l'$RDt.TYPEI,I'reF/IILLY'1 r' , 
ALARMSTYPE 
LITERALLY 
'11', 


wrITESTYPE 
LITERALLY 
'12'; 


Sln~lu~e 
(:fr:MSG.ELT) 


OF-CLARE 
MSG$HDR 
LJTERAL~Y 
LINK 
ADDRESS, 
LF:NG'CH !I,uDnESS, 
TYPE 
RY'JE, 
HOME~EX 
ADDRESS, 
RESPS8X 
ADDRESS'; 


DECLARE 
~1SGSDESCRJP1'OH 
LTTERflLLY 
'S'lRl)CTUHE( 


MSG~HDR, 
REr'll\ 
T/-JDEP. (1) 
BYTE)'; 


~Jnc]urie 
(:fr:1'H~SG.ELT) 
DECLA,RE 
THSjVJ~;GLJTEkALLY 
'STHlJC'j'IJH,F: 


MSGHDR, 
S'l',lI,'l'US 
ADDRESS, 
BlJFFER$ADP. 
ADDRESS, 


COUI-J'!' 
ADDHE~;~;, 


l'CTUAL 
l\DDHF.SS, 
REJVJI'.INDF:l;(12!J) 
BYTE')'; 
DECLARE 
MIN$'1'H$MSC$LENGTH 
L1TERALLY 
IJ7'; 


SInc]ude 
(:F0:CHflR.ELT) 


DF-CLl-HE 
NULL 
CCNTROLSC 
CONTRCU' 
E: 


BELL 
'1',\B 
LF 
VT 
FF 
CH 
CONTROL$P 
C0NTRCL$Q 
CON'rnOLSR 
CONTROL~S 
CONTROL$X 
CON'j'ROLS? 
ESC 
OlTon: 
LC'I\ 
LC7 
RUB OUT 


LI'1'EHALLY 
'(H'Il', 
LI~ERALLY 
'r3H', 
L[TE~ALLY 
'~5H', 
LITERALLY 
":7H', 
LITCBALLY 
'~9H', 
Ll'rERALL~ 
'('AH', 
LITERf,LLY 
'f BH' 
, 
Ll'l'ERlI,LLY'(:CH', 
LJTEJ<l\LLY 
'C'DH', 
LITERALLY 
'U~fl', 
LIT~RALLY 
'J1D', 
LITERALLY 
'J2H', 
LTTER1\LLY 
'131-1', 
LITERALLY 
'12H', 
LITERALLY 
'll\H', 
LITERALLY 
'lP-H', 
LITEr-ALLY 
'22H', 
LITERALLY 
'SIll', 
LITrRALLY 
'7AH', 
LITERALLY 
'7FH'; 


SInclu~r 
(:rr:SYNCH.EXT) 


R(\SEND: 


PRCCEOURE 
(EXCHANC~~PCINTER,MESSACE$POINTER) 
EXTERNAL; 
GECLARE 
(~XCHANGE~POINTER,MESS"GC~POINTER) 
~DDHESS; 


RQW ..•.,IT: 


PRCCEDURE 
(FXC~ANGESF01NTER,DELAY) 
AnDRESS 
EXTERNAL; 


DECLARE 
(EXCHANGE$POINTCR,DELAY) 
ADDRESS; 


I 7 
'/ 


Jr 


19 
., 
/. 


20 
7. 


21 
., ... 
7. 
<./ 


23 
7. 


2.'1 
] 


25 
J 
21'; 
1 


7.7 
1 


2 ~~ 
7.9 
] 


30 
1 


:'1 
I 
," 
1 
. ,. 
3:; 
J 


31' 
.l 
:!'i 
1 


:<G 


AD 


,op 


42 
"] 
1 


11 
2 
" 
2 
t. 
) 


I' 
2 


/I 
? 
4 
2 


5 
1 


HQJ\CPT: 
PRo('n~UHE 
(EXCH1\NGE~pC)rNT'.,R) 
!;[)l)P.ESS 
EXTERN1\L; 


DECLARE 
EXCHANGEtPOINTER 
~DDRESS; 


Ror;;ND: 
PROCEDlJRE 
(IED$PTR) 
EX'i'E:RN~L; 
D~CL~RE 
IED~PTR 
~DDRESS; 


E!\JD RCTSND; 
Decl?r2 
TEMPtC~LIBRATE(5) 
~~~(ess 
2xtern~J; 
Decl?re 
UPDATE~ExrA(5) 
~d~ress 
extern~l; 
ne~18re 
CRT~ST~TUS~RXCH(5! 
a~~r2ss 
externHl; 
Dec'pre 
COMPSEXCH(5) 
a~~rQss 
uxtern~l; 
Dec]~re 
CONSTANTStrCKOUTtEXCH('i! 
~~(lr2SS 
externFJ; 


Ceclc're 
RQOUTX(C,) 
?(:(1ress 
i~xL,.'rnal; 
Decl~(e 
R0INPX(5) 
;~~ress 
cx~~rnal; 
Dccl~rc 
WORDS$EXCH(5) 
address 
ex~erri?l; 
Declare 
SETPOIN'j'(4) 
address 
extern~l; 
DccJr:re 
'l'OLERAJ\ICE(I') 
;?(h~ress 
ext(!rni'1;; 
Dccl.are 
EUFFEH2 
Hlclrt'ss; 
Declare 
MSG$PTR 
2d~r2Ss; 
Declare? 
M~;G stfUr.!:I:(C 
( 
MSG$HDH, 
STATUS 
;;rlr1res~;, 
BUFFER$PTR 
od~rGss, 
rCUNT 
"'ddress, 
ACTUPL 
",~~[ess ); 
D0c]?re 
CAL$TEMp 
slru~ture 
MSG~:fiDR 
, 
Cl\L 
adrn~ss 
); 
r}(=cliHp. 
UPfJ$MSG cdcress; 
Dcc]?r~ 
ENERGIZE 
b2Se( 
UPDt~SG 
structure 
( 
~'SG::;HDR , 
STATUS 
<,c1d f-2SS, 
BUFFERSPTR 
~ddress, 
COUNT 
Cloc1r0ss, 
ACTUAL 
address 
); 


Declare 
ENABLES~SG 
structur€ 
( 
. 


MSG$HDR 
); 
De~12(~'RU~FER(Dr) 
byte; 
Dec12re 
OVEN 
byte; 
D8C~nEP: 
Proceclure 
(SOUHCr:., 
'j'ARGET) 
(·'xter 
nD1 i 
De~J~re 
(SOURCE;TARGET) 
~ddrRss~ 


end 
JlEC"nEP; 
A:?C::;2$8INAHY: 
Proce~ure 
(S0URC~.T~RGET,SlZE) 
byte 
external; 


De~lare 
(SOURCE,TARGET) 
address; 
Der.lare 
SIZE 
byt~; 
. 


end 
ASC$2$8INARYi 
DoclarE 
MSGSl(2r) 
byte 
data 
( 
ESC,'E' 
,'E~TER 
eVEN 
NUMBER-'); 


'XXXX.X-' 
);J 


~2 
D~C'~r0 
MSGS312S) 
byt~ 
~2ta 
r.R,LP, 
'ENTER 
NEW 
TOLERfNCE-', 


'XXXX.X-' 
)i 


53 
nerJ?r~ 
rALMPC(I?) 
byte 
dat~ 


''l'EMPERATllR~~-' 
) i 


54 
Derlvre 
Msr$t(~~) 
hyte 
(ata 
( 


CH,LF', 
, (S'rATUS- 
(~;), 
PlIRM'1E'l'ERS- 
(P), 
CI'.LLHl~NrE- 
Ie))' 
, 
CR,LF, 
'ENTER 
REQUES1-' 
); 


Declare 
WAIT 
liter21Jy 
'MSG$PTR='; 


D~ c J elf e 
F :)R 
1 i h, r n 11 y 
'R (W f. I 'f ' ; 


Declare 
START 
Ijtera~ly 
'CALL'; 


Declare 
TASK 
lite~~]ly 
'RCSlNO'; 


UPDl-.'fE: 
ProcC~Dre 
public; 


1* 
Initialize 
task 
rit 
stnrt-up 
tim~ 
*/ 
Do 
fore'/Ll 
i 


MSr;. RESP~ 
EX=. CO''1P$ EXCII i 


1* WDit 
fur 
request 
to 
enter 
t~Bk 
*1 
UPD$MSG=RQWAIT 
(.UPDATE~EXCH,r); 


11 
Get 
d0sire~ 
oven 
number 
from 
orer~tor 
*1 


RQST::OVEN: 
MSG.HUffERSrTR=.MSC$J; 
MfC.TYPE=WRITESTYPE; 
l>\f~G.r.CUNT=:?ri 
Start 
LVs~ 
(.RQOUTX,.MSG); 
I"'i,it 
for 
(.CO"'1F~EX(,H,(')i 


/* 
..• 
Inpllt: 
nel. 
number 
*1 
M~G.BUFFERtPTR=.BUFF8Hi 
ttiSG. COUNT=:' 
S 5 i 


MSG.TYPE=CLRSROSTYPEi 
~t? rt 
tAsk 
(. RQINPX, 
• [>\SG) i 


\-;dt 
[or 
(.COI'1P:;EXC'r.,r); 


OVEN=(BUFFFR(S) 
AND 
0'~)-li 


if 
0V~N 
>~ 
thcn 
go~to 
nQf1'~nV~Ni 


1* 
Cispl~y 
request 
~n~ 
CUI 
rent 
sctpoint 
*/ 
GET$'fEMP: 


('('1.1J 
movE' 
(28,.f'!SG~2,.BUFFEH); 


(' "J 1 
f; E C~' R E P 
(. 
S E '1' PO TNT 
( 0 V (' n) , • P U F F E H + 2 1. ) ; 
MSG.TYPE=WR1TE~TYPE; 


/'ASG.C0UNT=7.R; 
St;~rl: 
tclsk 
(.RQOU'l'X,.I·lSG)i 


w.-;it 
for 
(.COJVir~EXCH,f)i 


/* 
... 
Input 
ne\i 
setpoint 
*/ 
MSG.TYPE=CLRtHD$TYPE; 
Sr.art: 
task 
(.RQINPX,.MSG); 


IA1ift 
for 
(.COMPtEXCH,(.); 
If 
ASCS2SSINARY(.BUFFER,.BUFFER2,1)=r 
OR 
BUFfER:? 
> 7rr 


th,;T\ 
go;,to 
GE'i'~'I'EMPi 
. 


If 
BUFFER:? 
<> 'I 
then 
do; 
It.Ji'it 
for 
(.CON~;Tldn'$LOCKOU'l'tEXCH,('); 


SETPOINT(oven)=BUFFEH?; 
Stint 
tcsh 
(.(,ONST/'W"~LOCKClJT~EXCH,l<lf;G$P'1'H); 


55 
1 


Sf) 
1 
57 
1 


58 
')~ 


,,(' 
:~ 
~, 
3 
n.,," 


.,2 
3 


(.)J 
3 


"11 
3 


G5 
3 


50 
., 


fi7 
., 


(;8 
? 


I';~ 
:'\ 
-,'(7; 


71 
~ 
77- 
3 
7". 
3 


7"- 
< 


"/6 
3 


77 
-, 
78 
3 


79 
:>. 


8 (' 
3 


PI 
< 


82 
" 
PJ 
3 
34 
'3 


85 
J 


fn 
:< 


PC) 
" 
% 
4 


91 
4 


';;) -' 
J 


9tJ 
? 
95 
., 
% 
3 
97 
? 


913 
3 


99 
3 
170 
3 
If'] 
J 
10/ 
3 


] 04 
3 


]r'l 
!' 
H'"/ 
4 
100 
4 
109 
4 


] 1 0 
3 


111 
3 


112 
.,., 


U3 
3 


1]4 
3 


115 
J 
Ill) 
3 


lJ7 
3 
1113 
3 


119 
3 


1::' 
] 
J 


123 
3 


125 
4 


126 
4 
1/7 
4 


1211 
4 
1/9 
LI 


130 
" 
131 
4 
132 
4 
133 
4 
13" 
" 


136 
" 
137 
4 
13£ 
4 


l,t;T~TlIL: 
Call 
move 
(?9,.MSG$3,.I3UfFER)i 
Call 
DEC$REP 
(.TOLERANCECoven) 
,.BUFFERi?2)i 
MSG.TYPE=WRITE$TYPEi 
fV\SC.COUNT=29i 
StFtt 
tAsk 
(.RQOUTX,.MSG)i 
Wait 
for 
(.COMP$EXCH,O); 


i* 
... Input 
new 
toler?nre 
*/ 
MSG.TYPE=CLR$RD~TYPE; 
StClrt 
task 
C.RQ1NPX,.MSG); 


~~it 
for 
(.COMPSEXCh,0); 


If 
ASCS?$BINARYC.BUfFER,.BUFFER2,1)=0 
OR 
BUrf~R2 
> 
700 


then 
go$to 
GETSTOL; 
If 
BUFFER2 
<> 
(1 
then 
cio; 
Wait 
for 
(.CONSTA~T$LOCKOU~£EXCH,0); 
TOLERANCE(ovcn)=BUFFER2; 
Start 
task 
(.~ONSTPNTSLOCKCU7$EXCH,MSGSPTR); 


en(!; 


/- 
Ask 
operator 
if 
h~ 
is 
finished 
*/ 
REQ$NEXT: 
MSG.TYPE=WRITESTYPE; 
MSG.COUNT=('2; 
MSG.BUFFER$PTR=.MSGS4i 
St<:<l"t 
ti'lsk (.RQOUTX,.MSG); 


WQit 
for 
(.r.OMP$EXCH,0); 


i* 
...Get 
his 
r~spon5e 
*/ 


MSG.1YPE=CLRSnO$TYPE; 
MSG.BUFFER$PTR=.BUFFER; 
Start 
t.flsk (.RQINPX, 
.NSG); 
Wait 
for 
(.COl'lP$EXCH,~); 
If 
(bUFFERCP) 
<>'8' 
AND 
BUfFEH(0) 
<>'p' 
AND 
BUFFER(0) 
<> 
'C') 
then 
go$to 
REQ$NFX'l'; 
If 
BUFFER(V,)='P' 
then 
go$to 
RQSTtOVEN; 
If 
BUFFER(0)='C' 
. 


then 
do; 
GE'fSCAL: 
MSG.TYPE=~RITESTYPE; 
MSG. COUN'j'=12; 
MSG.BUFFER$PTR=.CALMSG; 
Stort 
tAsk 
(.RC'OUTX,.MSG); 
Wait 
for 
(.COMP$EXCH,E); 
MSG.TYPE=CLR$RDSTYPE; 
MSG.BUFFER$PTR=.5UFFER; 
St~lt 
task 
(.RQINPX,.MSG); 
Wait 
for 
(.COi"IP$EXCH,"); 
If 
ASC$2$BINARYC.BUFfER,.BUFFER2,1) 
=E 


OR 
BUfFER?>3S0 
OR 
HUFfER2<2r0 
then 
go$to 
GET$CAL; 
CALSTEMP.CAL~BUFF·ER2; 
Call 
RQSEND 
(.TEMPSCALIBR~TE,.CAL$TEMP); 


end; 
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MODULE 
INFORMATION: 
CODe 
AHEA 
SIZE 
V~RIABLE 
AREA 
SIZE 
MAXIMUM 
~TACK 
SIZE 
264 
LINES 
RElID 


V 
PROGRAM 
ERROR(S) 
END 
OF 
PL/M-e0 
COMPILATION 


f'3C 3H 
007CH 
0('Pl1H 


9(')]D 
12"D 
I!D 


ENERGIZE.TYPE=lO~; 
StCHt 
task 
(.CHT~ST.'\TUEt,EXCII,UPDtlV1SG); 


enc' ; 
end 
UPDATE; 


end 
UPDATE~TJ\SK; 


$TITLE('CHT 
UPDATE 
TASK'I 


/************************************************ 
* 
This 
task 
is 
utilize~ 
to 
up~ate 
th0 
CRT 
ter- 
* 


* 
minal 
display 
with 
the 
current 
oper2ting 
p~r- 
* 


* 
amcters. 
It 
will 
be 
entered 
upon 
syte~ 
st2rt- 
* 


* 
up, 
upon 
opvrator 
request, 
or 
when 
a 
problem 
* 


* 
exists 
with 
any 
of 
the 
activated 
ovens. 
* 


************************************************/ 
CRTSOATA$MODULE: 
Do; 
SINCLUDE(:F0:SYNCH.EXTI 
RQSEND: 
PROClmURE 
(EXCHJI.NG10.:$1;'01 NTER, f'olESSJI.GE 
SPO INTER) 
EXTERNAL; 


DECLARE 
(EXCHANGE$POJNTF.R,MESSAGE$POINTER) 
ADDRESS; 


RQ'f;AIT: 


PROCEDURE 
(EXCHANGE$POINTER,DELAY) 
ADDRESS 
EXTERNAL; 


DECLARE 
(EXCHANGFSPOINTER,DELAY) 
ADDRESS; 


RQ.I\CPT: 
PROCEDURE 
(EXCHl'-.NGf.$POJNTEH) ADDRESS 
EXTERNAL; 


DECLARE 
EXCHANGE$POINTER 
ADDRESS; 


RQISND: 
PROCEDURE 
(IED$PTR) 
EXTERNAL; 
DFCLARE 
IED$PTH 
ADDRESS; 


END 
RrTt:ND; 


SINCLUDE 
(:FP:MSGTYP.ELT) 


DECLARE 
~ATA~TYPE 
LITERALLY 
'0', 


INT$TYPE 
LITERALLY 
'1', 
MISSFD$INT$TYPE 
LITEkALLY 
'2', 


·'rrME~OU'r~TYPE LITERALLY 
'3 ", 
FS$REQSTYPE 
LITERALLY 
'4', 
UC$REQSTYPE 
LITERALLY'S', 


FS$NAKSTYPE 
LTTER~LLY 
'6', 
CNTRL~~C$TYPE 
'LITERALLY 
'7', 
READSTYPE 
LITERALLY 
'P', 
CLR~RD$TYPE 
LITERALLY 
'9', 


LASTSRDtTYPE 
LITERALLY 
'l~', 
ALARM$TYPE 
LITERALLY 
'11', 


WRITE$TYPE 
LITERALLY 
'12'; 


$INCLUDE 
(:FV:EXCH.ELT) 


DECLARE 
EXCHA~GE$DESCRIPTOn 
LITSRALLY 
'STRUCTURE 
( 
MESSAGESHEAD 
ADDRESS, 


MESSI\GE:~TldL 
]\DOHESS, 


TASK$HEAD 
ADDRESS, 


T~SKSTAIL 
ADDRESS, 


EXCHANGE~LINK 
ADDRESS) 
'; 


SINCLUDf 
(:F0:COMMON.ELT) 
DECLARE 
TRUE 
LITERALLY 
'0FFH'; 


DECLARE 
FALSE 
LITERALLY 
'r0H'; 


DECLARE 
BOOLEAN 
LITERALLY 
'BYTE'; 


DRCLnRE 
FOREVER 
LITERALLY 
'~HILE 
I'; 


SINCLUDE 
(:F0:MSG.ELT) 


DErLARE 
MSG~HDR 
LITERpLLY 
, 


LINK 
ADDRESS, 


LENGTH 
ADDRESS, 


TYPE 
BYTE, 


HOME~EX 
ADDRESS, 


RESP$EX 
ADDRESS'; 


DECLARE 
MSG$DESCRIPTOR 
LITERALLY 
,'STRUCTURE( 
MSG$HDR, 
REMf\INDER (1) 
BYTE)'; 


$INCLUDE 
(:F0:CHAR.ELT) 


DECLAIU: 
NULL 
CCNTROL~C 
CONTROL$E 
BELL 
TAB 
LF 


VT 
FF 
CP 
CONTROL$P 
CONTHOL$Q 
CONTROL$R 
CONTROL$S 
CON'rROL$X 
COWl'ROLSZ 
ESC 
QUOTE 


LITERALLY 
'r0H', 
LITERALLY 
'03HI., 
LITERALLY 
'ASH', 
LITERALLY 
"\7H', 
LITERALLY 
'VljH', 
LI,!'ERALLY '.rAH', 
LITERALLY 
'rBH', 
LITERALLY 
'eCH', 
LITERALLY'00H', 
LITERALLY 
'H'H', 
LITERALLY 
I I1H' , 
LITERALLY'12H', 
LTTEHALLY 
'J 3H' , 
LI'rERALLY 
'18H', 
Ll'I'ERALLY'lAH', 
L ITERA.LLY 
'IBH', 
LITEHALLY 
'2?H', 


Lez 
RUBOUT 
LI'['ERJl.LLY 
'7l\H', 
LITERALLY 
'7FH'; 


tINCLUDE 
(:FP:THMSG.ELT) 
DECLARE 
TH$~SG 
LITERALLY 
'STRUCTURE 
( 


MSGHDR, 
STATUS 
ADDRESS, 


BUFFER$ADR 
ADDRESS, 


COUNT 
ADDRESS, 


AC'rullL l\DDRESS, 
REMAINDER(l28) 
BYTE)'; 
DECLARE 
~IN~THSMSG$LENGTH 
LITERALLY 
1]7'; 


De~lare 
HOME 
literaJ~y 
'IBH,4PH'; 


Declal~ 
LISIMAGE(SP) 
byte 
data 
( 


Home,Lf,Lf,Lf,Lf,Lf, 
'TEMPERATURE 
' 


'DECREES 
C.' 
); 
Dec18re 
L2$IMAGE(92) 
byte 
0cta 
Hom~,Lf,Lf,Lf,Lf,Lf,Lf,Lf, 
'SETPOINT 
' 


'DEGREES 
C.' 
); 


Declare 
L3SfMAGE(94) 
byte 
data 
( 


~ome,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf, 
'TOLERANCE 
' 
, 


'DEGREES 
C.' 
); 


D~clare 
LA$IMACE(75) 
byt~ 
d~ta 
( 


Home,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf, 
'STATUS 
' 
OFF 
OFF 
OFF 
OFF 
') 
; 


Declare 
CRTSHDR(I~8) 
byte 
dat& 
IBH,~5H,' 
'OVEN STATUS 
DISPLAY', 
Cr,Lf,LE,' 
'OVEN-I 


'OVEN-:? 
'OVEN-3 


I OVEN-4 
1 , 


Cr,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,Lf,LE, 
Lf, 
, 


'TYPE Escppr 
TO 
~DJUSTSETPOIN~S' 
); 


Declare 
BRLLSf~) 
hyte 
~?ta 
( 
Be) 
1 , Be I J , Be 1J , Be 11 
); 
Declare 
MESSAGES(35) 
byte 
date 
OFF 
OK 
'Ci\U'l'IONI, 


• 
ALARM 
" 
, 
I 
); 
Declare 
DISPLAY$PTRI 
(11)" 
adilrN;s dati' 
( 


• WOH!<'SBL1FF+23, 
• "'IORK$BUFF+3 
6, 
• "'iOHK$eUFF+4S', 
• \'IORK$BUFF+52 
); 
Declare 
DISPLAY$PTR2(4) 
2ddiess 
data 
( 


I 
.WORK$BUFF+75, 
.WORK$BUFF+3P', 


.WOHK~BUFF+5J, 
• \"tOR!<~I3UFF+64 
); 


DecJare 
DISPLAYSPTR~(4) 
ad~ress 
data 
( 
• i'iORK$BUFF+27 
, 
.WORl<$BUFF+40, 
.1.rCRKSBUFF-t5:?, 
.WORKSBUFF+156 
); 
Declare 
DISPLAY$~TR~(4) 
2dd[~ss 
data 
( 
.WORKBUFF+3r, 
• WORI(bUFF+4:3, 
• 1,'ORKBUFf'+5 
5, 
• WCRI(8lJF F-t!) 9 
); 


Declare 
MSG$PTR 
address; 
Declare 
MSC 
based 
MSG$PTR 
structure 
( 
MSG~IlDR, 
COUNT 
?(ldress I;' 


Declare 
STARTER(3) 
structure 


MSCSHDH 
); 
, 


Declare 
R~AD 
structure 


MSG$IlDR, 
S1')\TUSnod ress, 
BUFFER$PTR 
~d~r~ss, 


COUNT 
a<'lilress, 


ACTUAL 
address 
); 


Declare 
DISPLAYSTE~P(41 
structure 
( 
UPPEP 
?c1(1ress, 


LOWE R 
20(1 r ess 
); 


Declare 
DISPLAY$SE1'(~) 
structure 
( 
LOj,\,'ER 
ad0ress, 
UPPER 
~cdress 
); 


Declere 
DISPLAY$TOL(4) 
stru~ture 
( 
LOWER 
acdress, 
UPPER 
address 
); 


47 
1 
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J 


50 
1 
51 
1 


52 
1 
53 
1 
54 
1 


55 
] 
51'; 
1 
5"7 
1 


58 
] 


59 
1 


or, 
1 


61 
1 


Ii? 
1 


03 
1 


(j4 
1 


65 
1 


f)1) 
1 
6"7 
] 


fin 
1 


6~ 
] 


70 
] 


71 
1 


72 
] 
73 
1 


74 
1 
75 
.1 


76 
] 
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1 
78 
J 
79 
1 


fW 
2 


81 
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Declare 
OVEN$ON(4) 
hyte 
d2t8 
( 
rlH,02H,r~H,0nH 
); 
Declare 
OVENSCJI.lJTION(11) 
bytE: Ci';ta 
( 
10H,2rH,~rH,80H 
); 
Decl?rL 
CRT 
structure 


MSG$HDR, 
STATUS 
i-ddress, 
BUFFERSPTR 
~ddress, 
COUI'iT ClO(lress, 
ACTUAL 
ad~ress 
); 
Declare 
CRTLOCK 
structure 
(MSG$HDH); 
Decl~re 
CRT$DISPLAY$LOCK(5) 
address 
extern~l; 
Declare 
TEi>1P$LOCKOU'r5EXcH (5) 
AOt1ress 
cxtf'rna'; 


Declare 
CONSTANT$LCCKOUT$EXCH(5) 
?rler~ss 
external; 


Declare 
CRTSEXCH(5) 
Fddress 
exturnal; 
Declare 
CRT$STATUS5EXCH(S) 
address 
external; 


Declare 
DUMMYSEXCH(S) 
address 
external; 
Declare 
READ$BUFFERSEXCH(S) 
address 
external; 


Declare 
UPDATESEXC-H(5) 
odoress 
external; 
Declare 
RQINPX(5) 
address 
external; 
Declare 
RQOUTX(5) 
~d~I'ess 
external; 
Declare 
RQt,<IAKE(5)ac1dress 
ext'ernal; 
Declare 
ROL7EX(5) 
Clddress 
external; 
DecJare 
RQLhEX(S) 
ac1dress 
external; 
Df:clc;re RQDBUC 
(5) ,'dcress 
extern<.:l; 
Declare 
RQALRM(5) 
AGOreSS 
extern21; 
Decl~re 
TrMP(4) 
nodress 
pxtern?l; 


Dec]~r€ 
DISP$TEMP(t) 
2edress; 


Declare 
SETPOINT(4) 
2ddress 
external; 


ueclare 
DISP$SETPNT(4) 
address; 
DeclRre 
TOLERANCE(~) 
address 
external; 
Declare 
DISrSTOL(4) 
6ddress; 


Declare 
STATUS(~) 
byte 
extern~l; 


Dec16re 
DISP$STAT(4) 
byte; 
Declare 
IBLOCKl,BLOCK2) 
byte 
external; 
Declare 
WORKSBUFF(]7~) 
byte; 
Declare 
BUFFER~A(7r) 
byte; 
Declare 
(CHANGE,n,ALARM,NEW,BLANKER) 
byte; 
Dec12re 
START 
literally 
'call'; 
Declare 
TASK 
literally 
'rqs~nc1'; 
Decl~re 
WAIT 
literally 
'msg~ptr='; 


Declare 
For 
literally 
'rgwait'; 
DEC~HEP: 
PrQceoure(SOURCE,TARGET) 
external; 
Declare 
(SOURCE,TARGET) 
address; 


end 
DEC$REP; 
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1111 
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P5 
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:? 


137 
2 


88 
2 
89 
J 
9r 
? 
91 
., 
-' 


93 
? 


9t1 
3 


9fi 
<! 


98 
11 
99 
L1 
HC 
4 


101 
4 


10? 
d 
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d 
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4 
1f~5 
" 
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t 


108 
4 
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4 


1 1(" 
11 
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4 


.112 
11 


.113 
3 
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3 
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4 
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4 
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J 


120 
3 
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3 


]:'3 
'! 
]211 
4 
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CRT$DATA$TASK: 
Proce~ure 
public; 
1* 
Initi~]izp 
system 
vt 
start-up 
time 
*1 
Start 
task 
(.TEMPSLOC~OUT$EXCH;.STfRTER(?)); 


S ta rt 
ta sk 
(. 
CONSTANT 
SLOe K~llJTSFXCf1, 
• STn R'!'Im ( 1 ) ) ; 
STARTER 
(?) 
• TYPE=10C'; 


~:;tn t 
task 
(JRT$STATUSSEXCII, 
.STARTF:H 
('2j); 
CRT.RESP$EX=.CRTSRXCH; 


1* Perform 
m~in 
CRT 
~Bit 
*1 
Do 
forever; 
'A!d t 
for 
(. DlJMMY$FXC11, 1r.) ; 


Wait 
for 
(.CRTSSTATlJSSEXCH,0); 
If MSC.TYPE=255 
then 
ALARM=l; 


e.1s(? 
ALARM=r; 
1* 
Output 
hea~ing 
*1 
If 
(MSG.TYPE=lrr 
OR 
MSG.TYPE=255) 
then 
do; 
If 
/I L1\ RI": = 0 


th~n 
ca)] 
RQSEND(.CRTSD1SPLAY$LOC~,.CRTLOCK); 
CflT. TYPF.;oy, 
f::JTESTYPE 
j 
CRT.COUNT"'167; 
CRT.BUFFER$PTR=.WORKSHUYf; 
READ.TYPE=CLR$RDSTYPEj 


[< El\D. CCUN'f=? ')5; 
READ.RESPSr,X=.READ$BUFFER$EXCH; 
IH~f\D~ 
B lJF FEH SPT [(=. PUFFEH1' 
; 
If 
ALt\RM=~ 
then 
start 
'ti.1sk 
(.RC'II\lPX.,.READ); 
CAll 
move 
(R2,.CRTSHDR,.WORK$BUFF); 
CeJ.1 
move 
U'fi, 
.CHTSHDR+r>2, 
.WORKSBUFF+R2); 
f:tc'rt tAsk 
(.RQOU'l'X,.CHT); 
\II/ait 
for 
(.CH'l'SEXCH,P); 
NEt-I=] ; 


end; 


1* 
Test 
for 
change 
in 
tcmper~ture 
of 
any 
oven 
*1 


CHANGE=r; 


We' i t 
for 
(. TEMPfLOCKOUTSEXCH, 
r) ; 
Do n=0 
to 
1; 
If TEMP(n)<>DISP$TE~P(n) 
then 
C!-J}\NGE=l; 


end; 
Call 
move 
(8,.TEMP,.DISP$TF~P); 


Start 
task 
(.TEMPSLOCKOUTSEXCH,MSGSPTR); 


1* When 
a 
change 
exists 
build 
new 
line 
*1 
If 
CHANGE 
OR 
NEW 
then 
00; 


C~11 
move 
(90,.Ll$I~AGE,.WORKSBUFF); 
Do 
n=r 
to 
J; 
CaJ 
l 
DEC$REP 
(. nISP$'I'EI~P 
(n) 
, DISPLAySPTRJ 
(n)); 


end; 


1* Output 
ne~ 
temperature'line 
to 
CRT 
*1 
CRT.TYPE=WRTTE$TYPE; 
CRT.COUNT=87; 
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H0 
3 
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" 
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4 
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5 
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5 
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4 


1" 8 
" 
111~ 
4 
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151 
I! 


157 
-:l 


15: 
3 


154 
3 
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l! 


157 
II 
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3 
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3 


16r. 
:' 


]<';2 
4 
Hi3 
" 
1 ')4 
5 
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') 
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" 
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11>8 
4 


1f19 
/I 
In 
/I 
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" 


172 
3 
173 
:3 
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Start 
task 
(.RQOU1'X, 
.CRT); 
Wait 
for 
(.CR1'S8XCH,Vl; 
. 


enc1; 


I~ 
Test 
for 
ch~nge 
in ov~n 
~etpoints 
*1 
CHANGE=" 
; 


WBit 
for 
(.CONSTANT$LOCKOUT~EXCH,G); 
Do 
n=~ 
to 
3; 
If 
S~TPUINT(n)<>DISP$SETPNT(n) 
then 
CHANGE=l; 


end; 
C~]J 
move 
(8,.SETPOINT,.DISPSSETPN~); 


Start 
task 
(.CONSTANTSLOCKnUT$EXCH,MSG~PTR); 


1* 
Bili Jd 
ne\,; 
line 
\,;hf~n ." chi"lnge 
\.as 
detected 
*1 


If 
Cf-l.a.NGE 
OR 
NE~, 
then 
(10; 
Ci"lJ 
move 
(92, 
.L7.$IMAGE, .\t\ORKBUFF); 
Do 
n = ~ t 0 
~~; 
('(' 11 
nEC$PEP 
(.DTSP$SETPNT 
(n) ,DISPL!\ySP1'R2 (n) ); 


enc1; 
11 
Out.put 
s~t:point 
]inc' 
*1 


CR7.TYPE=WRITE$TYPE; 
CRT.COUNT=8S; 
CR'J'. PUFF EH:~P1'R=. h'CRi{l3lJFf; 
St? rt 
task 
(. RQOUTX, 
.c:RT); 


W2it 
for 
(.CRT~EY(,H,V); 


end; 


1* Test: 
for 
c:hi'lnge 
in 
tolerance 
J i."'\£' */ 
Cf-!ANGE=0; 
N~it 
for 
(.CONS1ANT$Ln(,K0UT~EXCH,0); 


Do 
n=C 
to 
3; 
If 
TnLERANrE(n)<>nJSP~TOL(n) 
thf~n 
CHANGE=1; 


cnc1; 
CaJl 
move 
(8,.TOf.ERI\NCE,.T:'rSrSTOL); 


St~rt 
task 
(.CONS1ANTSLCCKOUT~EXCH,MSG$PTR); 
1* 
When 
ch~nge 
is 
found, 
huild 
new 
line 
-I 


If CHANGE 
OR 
NEW 


then 
do; 
Cn)] 
move 
(9lJ,.L:'SI/"lJl(;~;,.WORKS8UFF); 
Do 
n=~j 
to?; 
Cn] 
1 
DEeSREP( 
.DISP$TOL(n) 
,DISPLAY$PTR2(n)); 
end; 
/* Output 
t02erance 
lin~ 
*1 
CRT.TYPE=~RITESTYPE; 
CRT.COUI\!T=9]; 
CRT.BUFFER$PTH=.~ORKBUFF; 
St?rt 
ti'sk 
(.RQOUTX, 
.CR'i'); 
\~'ait 
fOI 
(.CRT$FXCH,?); 


end; 
1* 
Build 
st2tus 
~pssage 
*/ 
CHl\NGE=0; 
Wait 
for 
(.CONSTANT$LOCKOUT$EXCH,0); 
Do 
n=O 
to 
3; 


If STATUS(n)<>DJSP$~TAT(n) 
then 
CHANGE=;; 
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5 
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5 
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" 
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5 
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end; 
Call 
move 
(~,.ST1\TUS,.DISP$f,TII'I'); 


Start 
task 
(.CONSTANT$LOCKOUT$EXCH,MSGSPTR); 
/* 
Output 
to 
displ0y 
*/ 


If CHANGr. 
OR 
NEW 


then 
co; 
CalJ 
move 
(75,.LJ'Ii>1AGJ:;,.I';ORK$BUFF); 
Do 
n=V 
to 
:?; 
Call 
move(7,.MESSAGES+DISP$STAT(n) 
,DISPLAYSPTkJl( 


en0; 
CHT.COUNT="?!';; 
Stat 
t 
task 
(.ROOUTX, 
.CRT); 


hoit 
[or 
(.CRTSEXr.H,0); 


end; 
/* test 
for 
request 
to 
exit 
this 
mode *; 
MSG$PTR=ROACPT 
(.READ$BUFFERSEXCH); 


If 
AL/lRM=0 
then 
do; 
If 
(MSG$PTR 
<> 
r 
,HId 
BUl'FERA(0) 
= 
1P.H~ 


then 
<'0; 


MSCSPTH=RQ~AIT(.CRTSDJSPL/lYSLOCK,r); 
stHrt 
task 
(.UPDATESEXCH,MSG$PTR); 


end; 
e 1se 
(10; 
If MSG$PTR=0 
then 
STARTER(2) 
.TYPE=20F; 


else 
STARTER(2) 
.TYPE=lV0; 
St~rt 
task 
(.CRT$STATUSSEXCH,.STJlRTER(2»; 


NEI'f=O; 


end; 


enc; 
p.ne; 


en<'1CRTSDATA$TASK; 


end 
CRT$DATA$MODULE; 


MODULE 
INFORMATION: 
CODE 
AREA 
SIZE 
VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


3PE 
LINES 
READ 
o 
PROGRAM 
ERROR(S) 


,P2rH 
Cl189H 
0~'(IIJ1H 


Ifl2f.D 


303D 


-1D 


: 


to 
'2 
5 
2 
r) 
2 
of 
;;1 
8 
2 


S 
2 


10 
2 


1] 
3 


]2 
3 


J:> 
/. 


]L1 
2 


15 
3 


II) 
? 


18 
to 
l~ 
,. 


$TITLE('ASCTI 
STRING 
TO 
FIXED 
BTNARY') 
/**********Y*************i*************************** 
* 
This 
program 
converts 
Hn 
ASCII 
string 
into 
A 
fix- 
* 


* 
ed 
point 
binary 
numh~r. 
The 
fixed 
~ecimFl 
point 
* 
* 
is 
cle t.e rm i n('(] by 
t11e 
p in am E' t. e r 
p i'Jsse din 
S IZE • 
* 


*************************Y**************************/ 
ASC$2$BINARY$~ODULE: 
Do; 
/* SPECIAL 
ASCII 
CHARACTERS 
*/ 
DECLARE 


NULL 
CONTROL$C 
COt-''l'ROL$E 
BELL 
Ti\B 
LF 
V'1' 
FF 
CR 
CONTROL$P 
CONTROL~Q 
CONTROL$R 
CON"'RCU:S 
COJIITROL$X 
CONTROLSI' 
ESe 
QUOTE 
LeA 
ffZ 
RU80lJT 


LJ'l'EHALLY 
LITERALLY 
LJTER1"LLY 
LITERlILLY 
LJ'I'ERALLY 
LITERALLY 
LITERALLY 
L TTERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LI'l'ERJlLLY 
LIn:RALLY 
LI'l'EfV\LLY 
LITERALLY 
LITERALLY 
LI'fERALLY 
LITERALLY 
LITERALLY 
LITF:RALLY 


'0 CH I , 
'C']H' 
, 
'(15H ' , 
'C'7H' 
, 
'f'19H 
' , 
'0AH' 
, 
'('IBH I, 
'0CH 
I, 


I rDB' 
, 
'1 (.)H I , 


I I 1H', 
, ] 2H ' , 
'.1 'H', 
'1 8H' 
, 


I lAH 
I, 


I ISH' 
, 


I 2~H' 
, 
, ;;.1 H ' , 


I 7 J\ Ii I , 


I 7FH '; 


l\SC$;;1SBINJI.RY: 
Procedure 
(SRC$PTR,TRGTSPTR,SJ7F.) 
byte 
public; 


D~cla[e 
(SRCSPTR,TRGT$PTR) 
a~dress; 


Dec.1are 
(SCLJRCE 
bilsed 
~;RC$l'TH) (eV) 
byte; 


De~lare 
RESULT 
brsed 
TRGT$PTR 
address; 


Dee-lare 
(N,SI7E,K,DP,DIGJ'fS,Vl\LID) 
byte; 


Decl?re 
POWER(6) 
Dddress 
~ata 
( 


r.,l,Jril,Jl?:(l,lfH'0,H'""''' 
); 


/* Find 
loc~tion 
of 
decimal 
point 
Y/ 


n=f:;; 
~o 
while 
SOURCE(n)<>'.' 
AND 
fOURCEln)<>CR 
AND 
SOURCE(n)<>LF; 
n=n+l; 


end; 
DP=n; 


/* Provi~e 
correct 
number 
of 
digits 
to 
right 
of 
decim~l 
*/ 
Do 
n=r 
to 
SIZE; 


SOURCE(OP+n)=SOUnCE(DP+n+l); 
If 
SOURCE 
(DP+n) >:"19H 
OR 
SOURCE(OP+n)<3rH 


then 
do 
k=n 
to 
PIZE; 


SOURCEIDP+k)='0'; 


end; 


20 
3 


21 
2 


22 
2 


/.3 
2 
2l! 
3 


2fi 
l 
27 
2 


29 
2 
30 
2 


<2 
3 
13 
3 


311 
4 


.'15 
.., 


3") 
4 


37 
4 
3(; 
:3 


39 
;1 


40 
2 


41 
1 


end; 
/* 
Mark 
end 
of 
string 
*/ 
OIGITS=OP+SIZE; 
/* Test 
for 
all 
vali~ 
characters 
*/ 
VALID=1; 
Do 
n=0 
to 
DIGITS; 
If 
SOUBCE(n»3~.'H 
OR 
SOURCEln)<3r!l 


then 
Vl,LID=0; 


end; 
If 
DIGITS>5 


then 
Vl-,LIn=r,; 


/* Convert 
data 
to 
bindry 
and 
store 
*/ 
n=0; 
If 
VALrD=] 


then 
do; 
RESULT=0 
; 
Do 
•...!hile 
DIGITS 
> ~'; 
RESULT=RESULT 
l- ( 
( 


SOURCF.ln) 
f\ND 
rFE) 
* 
POWER(DIGIT2)); 


n=n+ 
J ; 
OIGITS=OIGITS-l; 
enc1; 
end; 


/* Return 
to 
calling 
prograD 
*/ 


Return 
VALID; 


end 
ASC$2SBINARY; 


end 
ASC$2$BINARY$MODULE; 


CODE 
AREA 
SIZE 


V~RIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


8(' LINES 
READ 


a 
PROGRAM 
ERROR(S) 


r178H 
0fH'.r.H 


0004H 


3760 
leD 
110 


1 


2 
1 


J 
] 


t1 
1 


5 
] 


r; 
] 


7 
1 


8 
J 
9 
I 
1 (1 
I 


tTITLE 
(I 
COMlViON 
VJI,RIAP 
LE 
SrfOHAGE') 
/************************************************** 
* 
This 
mor1u],~ 
cont.ains 
those 
'1c'riahles 
common 
to 
* 


* 
multiple 
tasks 
in 
the 
oven 
control 
~ppli~&tion. 
* 


**************************************************/ 
VARIARLESSTCRAGE: 
Do; 
Declare 
SETPOINT(4) 
a~dress 
public; 


Declar,~ 
TOLER1\.NCE(·~) 
':1(lcJrl~ss 
publ:ic; 
Declare 
TEMP(4) 
adJress 
public; 


Declare 
STATlJS(4) 
byte 
plJbli,~; 
Decl 
art' 
PLOCK" 
hyte 
publ 
i c; 


Declare 
BLOCKI 
byte 
public; 
Declare 
BLOrK2 
byte 
public; 


Declare 
BLOCK3 
byte 
public; 


end 
VARI]I,ELE~STORAGE; 


CODE 
ARE/'. 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


If) LINES 
READ 


P 
PRUGRAM 
EHROH(S) 


(\r ('(:1-' 
0("2rH 
"r'HH 


~'D 
32D 
VD 


1 


2 
1 


3 
2 
4 
2 


5 
2 


;:; 
2 


7 
2 
8 
2 


9 
2 
H' 
'1 
] 1 
3 
12 
2 


13 
2 
14 
3 
15 
J 
ll'i 
3 


] 7 
2 
18 
< 


2r 
3 
21 
1 


2? 
2 
23 
2 
24 
2 
25 
'2 
26 
] 


~TITLE('WORD 
TO 
ASCII 
CONVERSION') 
/**************************************************** 
* 
This 
routine 
converts 
R 
fixed 
point 
word 
in 
mem- 
* 
* 
ory 
into 
a 
4 digit 
plus 
1 decimal 
ASCII 
display- 
* 
* 
able 
number. 
Zero 
blanking 
is 
included. 
* 


****************************************************/ 
DEC~REP~'.I'·WDULE: 
Do; 


DrC$HEP: 
Procedure 
(SOUHCE,TARGE'I') 
pub',ir 
; 
Declare 
(SC:llReE,TARGET) 
i:lddress; 
gec]are 
ANSWR(S) 
byte; 
Declare 
(DISPLAY 
baser' TARGET) 
(5) 
byte; 
Declare 
NUMBER 
bi'lS8d 
SOURCE 
structure 
( 


ELEMENT 
2r'dress 
); 
Declr>re 
N 
byte; 
Declare 
CALC(5) 
address; 


/* 
Initialize 
*/ 
Do 
n=0 
to 
4; 


ANS~'R(n)='O'; 


end; 
CALC(A)=NUMBER.ELEMENT; 


/* 
Convert 
to 
ASCII 
*,/ 
Do 
n=1 
t.o 5; 
CALC(n)=CALC(n-I)/le; 
ANSWR(5-n)=(CALC(n-l) 
mod 
10) 
+ 
JeH; 
(~nC!; 


/* Perform 
zero 
blanking 
*/ 
Do 
n=~: t.o 
3; 


T f 
l\NS\>JR 
(n) < > 'e 
I 
then 
n=4; 


else 
ANS~iH(n)=' 
'; 
end; 


/* 
Format 
with 
Clecimal 
point 
*/ 


Call 
move 
/4,.ANSWR,TARGET); 
01 SPLAY 
(4)= ' • ' ; 
DISPLAy(h)=ANSWRI4); 


end 
DEC$HEP; 


end 
DEC$REP$MODULE; 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


40 
LINES 
RE1\i! 


(1 
PROGRAM 
ERROR 
IS) 


OF 
PL/M-S0 
CO~PILATION 


00EEH 
UHL!H 
00V4H 


2JRD 
200 
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I. INTRODUCTION 


The utilization 
of computers to provide control or 


monitoring 
functions 
for industrial 
processes 


frequently 
results 
in complex computer 
systems. 
Distributing 
the control 
and 
processing 
intelli- 


gence throughout 
the control 
network 
reduces 


significantly 
the complexity 
of the system while 


increasing 
the reliability. 
The physical 
areas 


being controlled 
or monitored 
by each portion of 


the distributed 
system will generally 
consist of a 


relatively 
small number 
of I/O functions 
which 


are related by some control algorithm. 


The Intel iSBC 569 Intelligent 
Digital Controller 


(IDC) 
and 
the 
iSBC 
941 Industrial 
Digital 


Processor (IDP) are a part of the expanding 
line of 


Intel products 
which are oriented 
toward filling 


the requirements 
of these systems. 
This applica- 
tion note deals with the use of these devices to 
provide 
control 
of a closed loop system 
using a 
version of the PID control algorithm. 


It is assumed 
that the reader is familiar with the 


basic concepts required to generate 
software and 


has had some experience with using a computer. 
This application 
note will then guide the reader 


through a typical application, 
explaining 
in detail 


the decisions 
which 
must 
be made 
in order to 


effectively 
utilize a microcomputer 
to provide a 


control solution. 


The 
application 
which 
has 
been 
chosen 
is 


considered 
to be typical 
of the type which lends 


itself to control. The mechanical 
aspects 
of the 


application 
will be explained 
so that the user not 
familiar with the particular 
machinery 
will be able 


to understand 
the development. 
It will be seen 


that the techniques 
used will apply to any other 


specific application. 


The emphasis 
of the note will be on the use and 


implementation 
of the 
hardware 
and 
software 


features 
of the digital 
processor 
and controller. 
The actual 
PID 
control 
algorithm 
will not be 


developed in this application 
note. 


Reasons 
for Intelligent 
Boards 


The advent 
of microcomputers 
and the resulting 


trend 
toward 
utilizing 
these 
devices to control 


processes 
has resulted 
in many cases where the 


overall 
system 
performance 
has 
deteriorated 


because of the demands 
placed on the processor. 


In these applications, 
the computer 
has become 
overburdened 
with 
control 
algorithms, 
alarm 


detection, 
communications, 
and the many 
other 


tasks 
required 
of it. The processor 
can be inter- 


rupted by time dependent tasks to the point where 
other processing 
tasks can not be completed. 


Presently, 
Intel 
provides 
two 
I/O 
expansion 


boards which are capable of handling 
portions of 


the 
processing 
load 
which 
formally 
required 


processor 
time. These two devices are the iSBC 
544 Intelligent 
Communications 
Controller 
and 
the iSBC 569 Intelligent 
Digital Controller. 
Tasks 
which involve communications 
or parallel digital 


I/O 
can 
now 
be offloaded 
without 
requiring 
valuable 
processor time. These boards 
can issue 


interrupts 
to the 
master 
or host 
processor 
if 


interaction 
with 
other 
processes 
or devices 
is 


required. 
This technique greatly increases system 


throughput 
by offloading 
the other bus master 


processors 
and 
by minimizing 
traffic 
on the 


Multibus system bus. 


In some cases, it will be found that the intelligent 
controller can function to control the process in a 
stand-alone 
environment, 
providing 
a more 
functional, 
low cost control system. 


The concept 
of offloading 
the 
processor 
of its 


input/output 
tasks can be developed on the iSBC 


569 controller through the use of slave processors 
which may be installed 
on the board to assist the 


host. The result is the ability to provide up to four 
processors on a single intelligent 
slave I/O board 


by using the concept of slave processors. 


The On-Board 
Slave 
Concept 


The 
utilization 
of the 
iSBC 
569 controller 
is 


enhanced 
through 
the 
use of On Board 
Slave 


processors 
(OBS). These devices 
distribute 
the 
system intelligence 
and offload the processor 
on 


the 
intelligent 
controller. 
They 
can 
provide 


custom digital interfaces 
with the various devices 


which may be connected to the I/O ports of the 
controller. 
The OBS device allows a designer 
to 


fully specify his control/interface 
algorithm in the 


peripheral 
chip without 
relying 
on the master 


processor. 
Three types of OBS compatible devices 


are available 
from Intel. These are: 1) Industrial 


Processors, 
2) Standard 
UPI devices, and 3) UPI 


8741A for custom applications. 
By combining the 


devices in various combinations, optimum solu- 
tions can be generated 
for different 
control 


applications. 
Before proceeding, we should cover the general 
characteristics of the OBS devices available for 
use in conjunction with the iSBC569controller. It 
willbe seen that careful selectionofthe properI/O 
controller chip can reducesignificantly the design 
effort required to provide a control solution. 


II. BASIC UNIVERSAL PERIPHERAL 


INTERFACE DISCUSSION 


With the introduction of the Universal Peripheral 
Interface, 
Intel has expanded the intelligent 


peripheral concept by providing an intelligent 
controller that is fully user programmable. The 
8741A is a complete single-chip microcomputer 
which connects directly to a master processordata 
bus. 
To fully understand the techniques used by the 
UPI 8741A devices, we must have a general 
knowledge oftheir characteristics. Only then will 
we feel comfortable in implementing a design 
which uses the components. 


Hardware 
Features 
Each Universal Peripheral Interface has 1Kbytes 
of program storage plus 64bytes ofRAMmemory 
for data storage. It has a powerful,8-bit CPUwith 
a 2.5 p'seccycle time and two interrupts. Over 90 
instructions 
are provided 
in its instruction 


set. Most instructions are single byte and single 
cycle and none are more than two bytes long. 
These instructions are optimizedfor bit manipula- 
tion and I/O operations. Special instructions are 
included to allow binary 
or BCD arithmetic 


operations, table lookup routines, loop counters, 
and N-way branch routines. 
The chip's 8-bit interval timer/event counter can 
be used to generate complextiming sequences for 
control applications orit can count external events 
such as switch closures and position encoder 
pulses. Software timing loopscan be simplified or 
eliminated by the interval timer. If enabled, an 
interrupt to the CPU can occur when the timer 
overflows. 
Two 8-bit bidirectional I/O ports are included 
which are TTL compatible. Each of the 16 port 


lines can individually function as either input or 
output under software control. 
The UPI microcomputer is fully supported with 
development tools. The combination of device 
features and Intel development support make the 
8741A an ideal component for low-speedperiph- 
eral control applications. 


Software 
Interface 
The OBS communicates with the processor on the 
host board by means ofdata transfers between its 
registers 
and the host board's 
data 
bus. A 


communication protocol has been defined which 
provides a set ofrules bywhich the processorsmay 
interact with each other. Two types of software 
protocol are currently 
defined. These are the 
"simple" and the "extended" protocol. Before 
attempting 
to utilize the ORS devices in an 


application, the conceptsused for the communica- 
tions must be fully understood. 
When used on one of Intel's single board compu- 
ters, the communication path is by means of the 
I/O ports on the host board. This means that two 
port addresses, an odd and an even location, are 
assigned to each OBSdevice. The even numbered 
port is used to transfer 
"data" 
between the 


processors. The oddnumbered portis usedto write 
commands into the OBS and to read its status. 
Each transfer between the host and the slave 
device consists of the movement of eight bits of 
information. 


Four of the eight bits available in the status 
message have been given predefined functions. 
The bit will be set (logical 1)when the correspond- 
ing condition exists within the OBS device and 
willbe reset (logical0)when the condition doesnot 
exist. The functions of the four bits are: 


Bit-O.Output Buffer Full (OBF). 


This bit indicates that the OBS has placed 
information into the transfer register and 
that the information is available to the host 
processor. It can be read by performing an 
input operation from the even numbered port 
assigned to the particular OBS. When the 
data has been read, the bit willautomatically 
be reset to indicate that no data is available. 
As we will see, this is one of the key features 
enabling efficient utilization of the host! 


slave relationships 
on single board compu- 
ters. 


Bit-I. Input Buffer Full (IBF). 
This bit is used to indicate that data has been 
placed into the input transfer 
register by the 


host device and that it has not yet been read 
by the slave. Data 
is transferred 
into the 


input register by means of the host perform- 
ing an output to the even numbered port of the 
OBS. The bit will be reset when the device 
reads 
the 
data 
from 
the 
input 
transfer 


register 
into its accumulator. 
Data 
should 


only be output to the OBS when the IBF bit is 
reset! 


Bit-2. FO Flag. 
Unlike the IBF and the OBF bits which are 
controlled by hardware, 
the FO bit is control- 


led by the 
device 
software. 
The 
normal 


function of the flag is to provide a lockout to 
prevent 
the host 
from sending 
more data 


until the previous data has been processed or 
the operation 
is complete. 


Bit-3. F1 is the Command/Data 
Flag. 
It is automatically 
set when the host sends 


either 
a command 
(odd numbered 
port) or 


data 
(even 
numbered 
port). 
A logical 
1 


indicates 
that a command has been sent and 


a logical 
0 indicates 
that 
data 
has 
been 


sent. This bit may also be cleared or toggled 
by the UPI software. 


These bits will provide normal 
communications 
between the master 
and slave processors. 


Figure 1 shows the sequence of operations 
which 


can be used by the host processor 
to establish 


communications 
with an OBS using the simple 


protocol. 
In Figure la, we see that all operations 


are initiated by the host. It will first verify that the 
IBF flag indicates 
that the input register is empty 


and 
available 
for receiving 
a command. 
The 


command 
is then 
sent 
to the 
odd numbered 


port. This command will inform theOBS that is to 
perform 
some 
task. 
The 
task 
may 
involve 
a 


requirement 
for more information 
to be sent to the 


controller 
and 
it may 
involve 
the 
controller 


returning 
some data to the host. Figure 1b shows 


the operations required for receiving data from the 
OBS. 


~y 


With 
these 
ideas 
in mind, 
we can 
move to a 


discussion 
of representative 
versions 
of the 


devices available 
for use on the IDC boards. 
We 


will then look at a typical application 
to see how 


they can actually 
be applied to solve a problem. 


Standard 
Universal 
Peripheral 
Controllers 


Intel presently 
manufactures 
three UPI control- 


lers for non-industrial 
applications. 
These are: 


1. 8278 Programmable 
Keyboard 
Interface 
2. 
8294 Data Encryption 
Unit 


3. 
8295 Dot Matrix Printer 
Controller 


These devices offer an "off the shelf' 
solution to 


many applications 
which might be encountered. 


The Intel 8278 is a general purpose programmable 
keyboard 
and 
display 
interface 
device. 
The 


keyboard portion can provide a scanned interface 
to 128-key 
contact 
or capacitive-coupled 
key- 


boards. 
The keys are fully debounced with N-key 


rollover 
and programmable 
error generation 
on 


multiple 
new key closures. 
Keyboard 
entries 
are 


stored in an 8-character 
FIFO with overrun status 


indication 
when more than 8-characters 
have been 


entered. 
Key 
entries 
set an interrupt 
request 


output to the master CPU. The display portion of 
the 8278 provides a scanned 
display interface 
for 


LED, 
incandescent, 
and 
other 
popular 
display 


technologies. 
Both numeric 
displays 
and simple 


indicators 
may be used. The 8278 has a 16 x 4 


display RAMwhich can be loaded or interrogated 
by the CPU. Both right entry calculator and left 
entry typewriter display formats are possible. 
Read and write of the display RAM can be done 
with auto-increment of the display RAM address. 
The Intel 8294Data Encryption Unit is designed to 
encode and decode 64-bitblocks of data using the 
algorithm specified in the Federal Information 
Processing Data Encryption Standard. The DEU 
operates on 64-bit test words using a 56-bit user 
specified key to produce 64-bit cipher words. The 
operation 
is reversible; if the cipher word is 


operated upon, the original test word is produced. 
Because the 8294 is compatible with the NBS 
encryption standard, it can be used in a variety of 
electronic funds transfer applications as well as 
other electronic 
banking 
and data handling 


applications where data must be encrypted. 
Finally, 
the Intel 
8295 Dot Matrix 
Printer 


Controller provides an interface to the LRC 7040 
Series dot matrix impact printers. It may also be 
used as an interface to other similar printers. The 
chipmay beusedin a serial orparallel communica- 
tion modewith the host processor. Furthermore, it 
provides internal buffering of up to 40 characters 
and contains a 7 x 7 matrix character generator 
which accommodates 64 ASCII characters. 


Industrial 
Digital Processor 


Intel produces the iSBC 941 Industrial Digital 
Processor (IDP) which is programmed to handle 
an assortment 
of typical 
industrial 
digital 


interfaces and transducers. 
The controller can 


function to provide any of the following: 


1. Scan up to 16inputs for a change of state. 
2. Provide up to 8 gated one-shot outputs. 
3. Provide eight gated outputs with program- 


mable pulse widths and periods: 


4. Provide monitoring ofup to 8input lines for 


event sensing or as a programmable divider. 
5. Provide the period measurement of up to 


eight inputs. 
6. Provide a frequency to count conversion of 


one input. 
7. Provide for the control of a stepper motor 


having up to eight phases. 


8. Provide a simplex asynchronous 
serial 


input. 


9. Provide a simplex asynchronous 
serial 


output. 


In addition 
to providing 
one of the above 


functions, the IDP can also handle simple parallel 
I/O through the unused port inputs or outputs. 


III. FUNCTIONS OF THE INTELLIGENT 


DIGITAL CONTROLLER' 


The iSBC 569Intelligent Digital Controller (IDC) 
is a versatile digital I/O processor. The IDC is 
designed to operate in a system using anyone 01 
the following three modes: 
1. Intelligent Slave 
2. Stand-alone System 
3. Limited Bus Master 
Additional power is obtained by the utilization of 
three OBS's to generate up to 48 parallel input/ 
output data lines. 


In the intelligent slave mode,the controller's RAM 
is shared between the on-board 8085A and the 
Multibus users via a dual-port controller. Thus, a 
single bus master can control several intelligent 
slaves using the dual-port RAM as the major 
communications path. Switches are provided on 
the board to allow the user to reserve lK bytes of 
RAM for use by the 569's processor only. This 
reserved memoryis not accessiblevia the Multibus 
system interface and does not occupy any bus 
address space. 
In the stand-alone mode, the entire system can 
consist of a single IDC, with cables, power supply 
and enclosure. An IDC can be installed 
at a 


remote site as a completely autonomous system. 
The IDC may also be operated as a limited bus 
master when it is the only bus master in the 
system. Expansion memory and I/O boards may 
be connected to the IDC via the Multibus system 
bus to increase the input! output capabilities. This 
mode could be used to configure one IDC as a bus 
master 
with additional 
IDC's as intelligent 


slaves. This mode is not available with any other 
bus masters such as iSBC single board computers, 
disk controllers, or DMA devices. 


Input/Output 
Functions 
The I/O interface betweenthe iSBC569Intelligent 
Digital Controller and the external devices to 
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which it is to be connected 
normally 
consists 
of 


various OBS devices. Each ofthese slaves has the 
ability to provide sixteen individual 
input and/or 


output 
lines. 
In addition, 
each 
provides 
two 


specialized 
input 
lines. The IDC is designed 
to 


accommodate 
up to three 
slave 
devices, so the 


normal I/O configuration 
of the board will consist 


of 48 digital data lines. If the specialized lines are 
considered, 
this 
number 
could 
be raised 
to 


54. Sockets 
are 
provided 
for the 
insertion 
of 


drivers 
or terminators 
for use on the 48 digital 


lines. The 6 special purpose lines can only be used 
as inputs and are provided with pull-up resistors to 
terminate 
the input signals. 


The 
driver/termination 
socket 
configuration 


limits the grouping of the I/O lines to be in groups 
of four. Any slave data line being used for an input 
must have its output latch placed into a logical! 
state so as to allow the input line to be controlled 
by the external 
signal. 


IV. APPLICATION EXAMPLE 


An example 
of the 
iSBC 569 controller 
in an 


application 
will help to explain 
the techniques 


used 
to implement 
a control 
system 
and 
to 


interface 
between 
the various 
functional 
units. 


The application 
chosen will consist of a typical use 


but will be simple 
enough 
to allow the design 


operations 
to be easily followed. 


Suppose 
we choose to design 
a control 
system 


which will be produced as a subsystem to interface 
with 
and control 
a liquid applicator. 
As we go 


through 
the steps required 
to design 
and imple- 


ment such a control system, we will see how the 
various 
hardware 
and software 
tools which are 


available 
from Intel can be utilized to allow easy 


implementation 
of the task. 


Before proceeding, 
we will spend some time to 


insure 
there is a clear understanding 
about the 


definition 
of the liquid 
applicator. 
When this 


definition 
is complete, the design of the control 


subsystem 
can begin. 


A liquid applicator 
consists of two functional 


parts: 
a device to control the flow of a solid 


material, and a deviceto control the flowofa liquid 
onto the material. Wewill actually be controlling 
two continuous process loops which are related by 
an input parameter which specifiesthe percentage 
of liquid to be applied to the dry material. 


Figure 3 shows the components making up a 
typical weighbelt feeder. The operation of the 
feeder is straightforward. 
The vertical gate is 


adjusted 
manually 
to provide a desired gap 


between the conveyor belt and the lowerportion of 
the gate. This will result 
in a nearly 
level 


distribution of material on the belt when it is 
moving. The weighbelt is connected to a load cell 
to provide information back to the control system 
giving the amount of weight on the belt at any 
instant. If weknow the speed ofthe conveyor, it is 
simple to compute the amount ofmaterial flowing 
through the feeder during any time period. This 


flowrate is known as the Mass Flow and is usually 
expressed as pounds per minute. The control of 
the feeder system can be provided by varying the 
belt speed until the desired flow rate has been 
obtained. 


Our control system will be designed to control the 
belt speedand to monitor the weighbelt weight and 
any other parameters which we determine will be 
necessary to control the flowofmaterial. Atypical 
control process will require an optimum flow rate 
be established for each material of a different 
density. With a known material flow through the 
feeder,we can go about the process ofapplying the 
liquid flow to the material in order to complete our 
application example. 


The secondloopofthe example willinvolve adding 
the liquid to the material coming from the feeder 
mechanism 
described 
above. Normally, 
the 


percentage ofmaterial to be applied is fixed by the 


formula or mix design ofthe product which we are 
manufacturing. 
However, 
since 
the 
flow rate 


through 
the weighbelt 
feeder can and does vary 
(our first control loop will not always 
be able to 


exactly 
control the flow due to many 
conditions 


beyond 
our control), 
the 
liquid 
setpoint 
will 


constantly 
be changing 
as a function of the actual 


mass flow and the liquid percentage. 


Figure 
4 shows 
the 
liquid 
application 
piping 


diagram 
for the 
liquid 
portion 
of the 
control 


system. 
The items with which we will be directly 
concerned are the liquid flow meter and the control 
valve. 
The 
other 
components, 
while requiring 


consideration 
in an actual implementation, 
will be 


ignored 
in this 
aplication 
note for the 
sake of 


clarity. 
Let us consider the details of each control 


loop in more depth before we attempt to design the 
control system. 


Mechanical Specifications 


In subsequent 
portions involving 
development 
of 


the control system, we will be constantly 
referring 


to data regarding 
the mechanical 
specifications 
of 


the liquid 
applicator 
system. 
Therefore, 
we will 


establish 
a set of theoretical 
technical 
specifica- 


tions for our system. 
Later, we will see how close 


the control system can come to providing a control 
which meets or exceeds these parameters. 
These 


specifications 
will be broken down into two sets of 


data, one for physical 
parameters 
over which we 


have 
no control, 
and 
a second 
for the 
desired 


control characteristics. 


The physical 
data 
provides 
information 
on the 


mechanical 
design and will be used for guidelines 


in selecting interface equipment 
and in preparing 


software 
algorithms. 
The physical 
data is: 


Operating 
Belt Speed - 
1.1 to 180 feet per minute. 
Adjusted 
by a 


variable 
speed motor directly coupled to the 


belt pulley mechanism. 


Feed Output Rates - 
Adjustable 
over a 10:1 range 
with a maxi- 


mum output of 960 pounds per minute. 


Feeder Belt Characteristics 
- 
The belt will be 9 inches 
wide by 2 feet in 


length when installed. 
The belt pulley rollers 


will have a radius 
of 4.5 inches. 
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Feeder Weight Sensor - 


The weigh belt feeder will incorporate 
a strain 


gauge load cell to measure the weight on the 
belt. Its linearity 
shall 
provide 
0.1% of full 


scale range. 


Liquid Flow Rates - 


The liquid flow rates shall vary between 10.0 
and 120.0 pounds per minute. 


The 
desired 
operating 
characteristics 
of our 


control system will provide the following general 
responses: 


Feeder Accuracy 
- 
1%of full scale over a 10:1 range. 
The feeder 


will maintain 
the set feed rate within 
1% of 


full scale over anyone 
minute 
period. The 


minimum sample must be at least one pound. 


Liquid Accuracy 
- 
1% of full scale over the operating 
range. 


Must be able to track mass flow variations 
within the above limits. 


These 
specifications 
will provide 
guidelines 
for 


the 
decisions 
which 
we will 
later 
make 
in 


providing 
a micro-computer 
control solution to the 


weigh belt feeder application. 


Interface Requirements 


A logical place to begin the consideration 
of the 


control system design is to examine the interface 
requirements 
and define the characteristics 
of the 


interfaces 
which will be required to implement the 


control. 
We will consider 
each 
element 
of the 
physical 
system separately. 


Weigh belt Weight 


The weighbelt weight will be sensed using a lever 
system 
connected 
to a load cell integral 
to the 


mechanical 
unit. The 
output 
of a strain 
gauge 


load cell is a low level (approximately 
20 millivolts 


at full scale) analog output. 
Obviously, this signal 


must be somehow 
converted 
into a digital 
level 


before we can use its information 
to compute the 


actual mass flow across our weigh belt feeder. Our 
design process must define the characteristics 
of 


the digital signal so that the appropriate 
analog to 


digital 
converter 
system 
can 
be chosen. 
The 


design path can take any of several equally valid 
approaches, 
any 
of which 
will provide 
a func- 
tional 
control 
system. 
For the purposes 
of this 


application 
note, we will assume that the design 


path 
will utilize the Intel iSBC 569 Intelligent 


Digital Processor. 


This assumption 
requires us to utilize only signals 


which can be generated 
or interpreted 
using the 


computer board and its associated 
OBS's. 
We will 


not 
be capable 
of handling 
an analog 
signal. 


Since some type of signal conditioning 
would be 


required of the low level analog voltage anyway, 
this does not impose any serious restrictions 
on 


our design. 
Indeed, it will cause us to consider 
a 


technique which provides excellent noise rejection 
characteristics. 
We will assume that a voltage to 


frequency 
converter 
(VIF) will be installed 
near 


the 
load 
cell and 
the 
frequency 
will then 
be 


transmited 
over a pair 
of wires to our digital 


interface. 
Commercially 
available 
converters 


provide a frequency output which varies between 0 
and 
10 kilohertz. 
With 
this 
in mind, 
we can 


continue 
with the development 
of the interfaces 


required in the application. 


The load cell transducer 
will incorporate 
a local 


unit 
which 
generates 
a pulse 
train 
whose 
fre- 


quency is proportional 
to the weight upon the load 


cell. This mechanical 
arrangement 
is typical 
of 


many gravimetric 
feeder systems 
in use today. 


For purposes ofthis application, 
it will be assumed 


that 
the 
system 
will be calibrated 
such that 
a 


weight 
of 10.00 pounds 
on the weigh belt will 


produce 
a pulse train 
frequency 
of 10 khz. No 


weight on the belt will generate a frequency ofless 
than 
30 hertz. 
The accuracy 
of the pulse output 


will be guaranteed 
to be proportional 
to the weight 


within 
0.05%. Again, 
this 
is typical 
of devices 
available 
and in general 
use in similar 
applica- 


tions. 


The characteristics 
we have described above fall 


within 
the performance 
range 
of the iSBC 941 


processor when operated in its frequency to count 
mode. If we assume 
a sample 
rate of 200 msec 
(this value 
should 
provide 
an adequate 
control 
characteristic 
since 
it is 
unlikely 
that 
the 


mechanical 
equipment 
can 
respond 
rapidly 


enough 
to warrant 
a faster 
control 
and sample 


time), the frequency 
count read by the iSBC 941 


counter 
will range 
between 
6 and 2000. System 


accuracy 
of reading 
the 
belt 
weight 
will thus 


exceed 0.1 % of the full scale weight reading. 


We will discuss the electrical and programming 
interfaces in subsequent sections of the applica- 
tion note. 


Weighbelt Motor Control 
The flow on the weighbelt will be controlled by 
changing the speed of the belt movement. Since 
the weighbelt is mechanically designed to main- 
tain a constant bed level, the amount of material 
flowing will thus be adjusted. 


The belt speed has traditionally been adjusted 
using either SCR controllers or by using variable 
transmissions 
between the motor and the con- 


veyor belt. The increased utilization and develop- 
ment of stepper motors is leading toward greater 
use ofdirect stepper motor drives. This is the mode 
which will be utilized for this application. 
The manufacturer's specifications for the weigh- 
belt indicate that the followingrequirements exist 
for driving the device: 
REQUIRED TORQUE - 
149LB-IN-IN 


REQUIRED MAXSPEED - 2.54REV/SEC. 
Referring to typical manufacturer specification 
sheets for stepper motors, we find the torque vs. 
speed characteristics 
shown in Figure 5. Our 


application requires 2.54 revolutions/sec which 
translates 
to 508 steps per second when the 


stepper is used in a 1.8degree per step mode. We 
can see that the requirements fall well within the 
capabilities of the particular motor. 


At this point, we have four routes which may be 
pursued to actually interface with the motor. These 
are: 
1. Utilize the iSBC 941 stepper mode to drive 
the stepper motor directly. 


2. Utilize the iSBC 941 frequency generation 


mode to drive a standard stepper translator. 


3. Utilize parallel outputs to provide a digital 


output to a stepper translater. 


4. Utilize a 4-20ma. current signal to a stepper 


translator. 


Three of the above modes use a translator to drive 
the motor. If possible, 
we should 
strive 
to 


eliminate the cost of this intermediate device. 
Again, we will refer to the published 
motor 


specification sheets. For our typical motor, the 
data is shown in Figure 6. The requirement for 
providing in excess of six amperes per winding 
exceeds the capabilities 
of the output drivers 
which can beinstalled on the iCS 930termination 
board. Wewill be forced to either design a custom 
high power driver board or to use a translator 
module. To keep the application as simple as 
possible, we will choose the latter. 


Motor 
Time for 
DC 
Amperes 
Resistance 
Inductance 


Type 
One Step Volls 
Per Winding 
Ohms 
Millihenries 


Ourlype 
1.7 msec 
2.3 
6.1 
0.37 
2.4 


Wehave three choices left when the decision has 
been made to use a translator module. The useof a 
current output mode will necessitate the use of an 
external analog board. This is undesirable, both 
from the standpoint ofinterboard communication 
requirements, and from a cost effective basis. 


The use of a parallel output wouldcommit many of 
our output data ports and would require the 
installation of UPI modules oriSBC 941modules 
to get the parallel output drivers. In addition, 
parallel digital input is not a common option of 
commercially available translators. 


This leaves us with the use of a variable frequency 
output 
to provide 
stepping 
information 
to the 


translator 
module. This is a normal 
operational 


mode of the iSBC 941 processor and the required 
508 hertz is within the normal output range of the 
device. 


A definite 
advantage 
of our decision 
to use a 
stepper motor drive for the weighbelt is that we do 
not have 
to maintain 
accurate 
feedback 
and 


control 
algorithms 
to maintain 
the conveyor 


speed. Only a simple check need be made to verify 
that 
the conveyor 
has 
not stalled. 
The stepper 


motor will inherently 
maintain 
a speed propor- 


tional to the frequency rate. 


The actual electrical and programming 
interfaces 
will be discussed 
in subsequent 
sections 
of this 


application 
note. 


Weigh belt Speed Measurement 


We have mentioned that a control system using a 
stepper 
motor 
for speed 
control 
can 
operate 


effectively 
in an open loop configuration. 
How- 


ever, since 
a faulty 
component 
could result 
in 


failure of the motor to run, we must verify that the 
belt is indeed moving. 
This is easily accomplished 


by adding 
a magnetic 
sensor 
to the weighbelt 


rollers and counting 
the pulses generated 
as the 


device operates. 


Typical 
magnetic 
sensors 
and ring magnets 
for 


installation 
on the weighbelt will provide us with 


ten pulses per revolution of a belt pulley. Since the 
pulley is operating 
at a maximum 
speed of 2.54 
revolutions 
per second, we will receive between 0 


and 
25.4 counts 
per second. Using 
our sample 


period of200 milliseconds, 
this means that we will 


count between 0 and 5 counts during 
each time 


interval. 
Our decision to use a stepper control loop 


rather 
than 
a conventional 
closed 
loop seems 


justified 
as we would obtain rather 
poor control 


with feedback having 
this poor of resolution. 


We must make a decision to determine 
how the 


speed will be sensed 
by the control 
board. 
An 


obvious choice would be the use of an iSBC 941 
processor 
operating 
in the period measurement 


mode. This would require using our third socket 
on the iSBC 569 host board and would leave us 
without the ability to use an additional 
device to 


support the liquid control loop. We should seek an 
alternative 
solution. 


The iSBC 569 controller 
board provides 
an 8253 


programmable 
interval 
timer. A first 
approach 


might 
be to attempt 
to configure 
one of these 
counters 
to provide an event counting 
mode and 


read the belt speed from the counter. 
However, 


this is not possible since we would be required to 
zero 
the 
counter 
after 
each 
reading 
and 
the 


counter does not load the preset count until a clock 
pulse 
is present. 
We would have 
no ability 
to 


distinguish 
between no belt motion and the belt 


motion which is the same as the previous reading! 


An alternative 
approach 
is to create a software 


counter by routing the belt movement pulse to one 
of our interrupts 
and creating 
a program 
which 
will increment 
a counter. 
Each 
time a count is 


sensed, 
the software 
will increment 
a memory 


location by an increment which corresponds to the 
speed represented 
by one count. 


Again, 
we will 
delay 
the 
discussion 
of the 
electrical 
and 
programming 
interfaces 
until 


subsequent 
sections of this application 
note. 


Liquid Flow Control 


The design of a control system to provide control 
of flow through a liquid valve is an integral part of 
the liquid pipe and plumbing design. 
To optimize 


the system operation 
and provide a system at the 


minimum 
cost, the integration 
of control 
and 


mechanical 
design must be made. 


Several possibilities 
exist when making a decision 
as to which control valve to use in adjusting 
the 


liquid 
flow rate. 
The 
actual 
selection 
of the 


physical 
valve mechanism 
should be based upon 


the 
characteristics 
of the 
liquid 
flow. 
This 


decision is outside of the scope of this application 
note and will not be pursued. 
However, the valve 


actuator 
is a device which becomes an integral 


part of the control system 
and its selection is a 


function of the control system design. 


Figure 
7 shows the common control valve types 


which are used to vary the flow rate of liquids. 
The automatic 
control system 
we are designing 


precludes 
the use of a manual 
valve, so we must 


make our selection between the air actuated 
and 


the motorized control valve. 


Classical 
control design has utilized air actuated 
valves almost exclusively. 
This type of actuator 


incorporates 
an 
intermediate 
transducer 
to 
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convert the signal generated by the control system 
into a variable 
air pressure. 
This air is used to 


drive a pneumatic 
control actuator. 
Two types of 


electrical 
to pneumatic 
transducers 
are in com- 


mon use. The most prevalent 
converts 
a 4 to 20 


milliampere 
control signal into a proportional 
air 


signal. 
The second type will accept a 0 to 10 khz 


pulse train and convert this to an air output. 


Both 
of the 
above 
systems 
provide 
excellent 


electrical 
noise 
immunity 
and 
give 
reliable 


operation 
in industrial 
environments. 
They do, 


however, 
have 
disadvantages. 
A supply 
of air 


must be present at the control devices and this air 
must be maintained 
such that it is free from water 


and 
oil. In 
many 
cases, 
this 
presents 
costly 


installation 
and 
maintenance 
considerations. 
The use of computerized control systems has led to 
a recent concept of eliminating 
the intermediate 


conversion 
and using instead 
a digitally 
control- 


led actuator. 
A stepper motor can be connected to the actuator 


of the 
control 
valve 
to provide 
a simple 
and 


economical 
control 
path. 
The control 
outputs 


from the PID control loop can be sent to the iSBC 
941 processor's 
command queue and the controller 


will handle 
the motor movements. 


The electrical and programming 
interfaces 
of this 


interface 
will be fully 
discussed 
in subsequent 


sections. 


Liquid Flow Measurement 


The use of a liquid control valve to vary the liquid 
flow cannot 
in itself provide an accurate 
control 


loop. Because the flow rate through 
a fixed valve 


will vary with material 
densities, 
temperatures, 


and 
pressures, 
we must 
provide 
some type 
of 


feedback 
into 
our control 
algorithm. 
Thus, 
a 


flowmeter 
must be inserted 
into the liquid flow 
and its output retumed 
to the system. 


The control 
system 
designer 
can choose 
from 


several types of flow meters depending 
upon his 


requirements. 
Figure 8 shows many of the more 
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standard 
classifications 
of flow meters. 
Our 


selection of the meter must take into account the 
type of electrical interface available from the 
meters. In our attempt to maintain 
a digital 


system which does not require additional support 
boards, we will reject the use, of a magnetic 
flowmeter because this type of meter provides an 
analog type of output which would require the 
addition 
of another 
board into our control 


system. The wobblemeter provides a digital pulse 
type output but its accuracy tends to discourage its 
use in a refined control loop. We will utilize the 
turbine meter for our liquid flow application. 
The output of a turbine meter is a lowvoltage, low 
current AC signal whose frequency is proportion- 
al to the liquid flow rate. The manufacturers of 
the meters provide pre-amplifiers which convert 
the signal into 10volt peak to peak square waves 
which are equivalent in frequenacy to the AC 
pulses. The operating frequency ranges typically 
from 100to 1200pulses per second. 
It is desirable to measure the flow rate using a 
single iSBC 569 controller. If we consider that a 
200 millisecond control interval will be used, the 
flow will result in a reading of between 20and 240 
pulses per sample period. These readings couldbe 
performed using an iSBC941processor, but wedo 
not have the socket available for a fourth module, 
so we must consider utilizing another interrupt 
driven software counter as was done with the belt 
speed. 
All control and monitoring equipment for our 
liquid control application has now been definedin 
such a manner as to be compatible with the 
utilization' 
of a single 
iSBC 569 controller 


board. The actual 
interfaces 
to perform the 


interconnections and to provide control instruc- 
tions can soon be considered. 


Operator Interface 


Finally, we must define the data c~mmunications 
which must take place between the controller, 
other system tasks, and the operator. Let us first 
consider the system control variables and the data 
which, if generated by the control process, might 
be useful to the remainder of the control system. 


The first variable which comes to mind is the 
liquid flow setpoint. If we consider the entire 


control system, this parameter will be found to be 
actually expressed as a percentage of the total 
output material. For example, if we assume the 
recipe required the final product to consist of 5% 
liquid by weight, wewouldrequire that ourcontrol 
system add the correctamountofliquid to perform 
this task. 


To allow maximum flexibility 
of the control 


system, we should allow selection of various 
density materials 
onto the weighbelt. A host 


processor with computational 
capabilities can 


calculate the optimum gravimetric feederflowrate 
for the materials being combined. 


The control system can provide an integration 
function to allow totalization of the amount of 
material which has been transferred through the 
system. A capability of outputting the amount of 
material which has passed overthe weighbelt and 
the amount of liquid added will be included. 
The implications of the parameter storage and 
generation 
will be dealt with later when the 


host/slave relationships ofthe iSBC569controller 
are discussed. 


Interface 
Summary 
Wehave definedthe required interfaces which will 
be needed to perform our control task. These can 
be grouped into external and internal interfaces. 
The external interfaces are those which connect to 
physical pieces of external equipment. 
These are summarized in Figure 9. The internal 
'interface relates to the data which is to be passed 
between the iSBC 569Intelligent Slave board and 
other 
boards 
which may be present 
on the 


MULTIBUS system bus. These data areas are 
shown in Figure 10. 


V. HARDWARE CONFIGURATION 


- 
We have now defined the various components 
which we will utilize on the controller board to 
support the physical control and monitor hard- 
ware. Our next task is to provide an interface 
between the controllers and the equipment which 
we are to control. In so doing, we will define the 
hardware 
I/O assignments 
for the iSBC 941 


processors and for the counters which we will be 
utilizing. The following paragraphs 
will deal 
with the optimization of this configuration. 


• • • • DEVICE ••••••••• 


WEIGHBEL T MOTOR 
WEIGHBEL T WEIGHT 
WEIGHBEL T SPEED 
LIQUID VALVE 
LIQUiD FLOW 


•••• 
SIGNAL TYPE' 
• • • • •• 
• ••• 
BOARD ELEMENT' 
••••••• 


10 VDC PULSE 
iSBC 941 
10 VDC PULSE 
iSBC 941 
110 VAC PULSE 
B259A INTERRUPT 
5 VDC MUL TIPHASE 
iSBC 941 
10 VDC PULSE 
B259A tNTERRUPT 


Figure 9. Control/Monitor 
Signals 


••• 
INPUTS···················· 
OUTPUTS···· 
GRAVIMETRIC 
FLOW 
ACCUMULATED 
SOLIDS 


LIQUID PERCENTAGE 
ACCUMULATED 
LIQUID 


Figure 10. Communication 
Signals 


Controller Interface 
Good design practice dictates that we should 
provide optical isolation between the controller 
and the external equipmentwhen designing for an 
industrial environment. The optical isolation is 
included if we utilize the Intel iCS series of signal 
conditioning/termination 
boards. Wefind that 


we have two types of digital termination panels 
available, 
one for low current, 
low voltage 


applications and second for higher current and 
voltage uses. If we base our choice on the data 
provided by Figure 8,wewilllean toward using the 
iCS 930 panel for our interface. This board can 
handle a mixture of signal levels and willsupport 
up to sixteen individual lines, providing almost 
double our needs. 


Even a cursory glance at the iSBC 569controller 
will provide the knowledge that 
three edge 


connectors are utilized to bring the OBS signals 
from the board. This would indicate that the 
simplest (and most costly)solution is to use three 
termination panels. Obviously,weshould investi- 
gate further beforemaking such a decision. Three 
possibilities are readily apparent. First, wemight 


perform some type of re-routing of data lines on 
the board so as to use only oneconnector. Second, 
we can use morethan one connector on the ribbon 
cable and perform a parallel connection of the 
various 
lines 
and choose them 
so that 
no 


duplication of lines results. Finally, we can use 
some scheme of connecting three cables to the 
board and use the optional Port C connectors on 
the termination panel. 


The schematic drawings of the IDC indicate that 
only six of the OBS 110 lines of each processor 
socket are broken by wire wrap jumper posts. All 
of the lines so configured are on the Port 2 data 
lines. Unless we decide to cut etch and add 
solderedwires, wewillnot be able to configure our 
board with this technique. Some further investi- 
gation is in order before we can make a decision. 
The use of a parallel output technique using 
multiple connectors on a single cable seems to 
present a feasible approach if we can work out an 
assignment of 110 which will not cause conflicts. 
Wewill begin by building a trial port assignment 
table in which we will assign 
the required 


functions to input! output ports. Wewillgroupthe 
inputs and outputs into groups of four to handle 
the terminator/driver arrangement which is built 
into the board. This table is shown in Figure 
11. Weobviously have a small problem. Wehave 


Socket 1 
Socket 2 
Socket 3 
Direction 


Port 


10 
Weight In 
In 
11 
In 
12 
in 
13 
In 
14 
15 
16 
17 
20 
Conv. Mtr. 
Out 
21 
Out 
22 
Out 
23 
Out 
24 
Valve Ph. 1 
Out 
25 
Valve Ph. 2 
Out 
26 
Valve Ph. 3 
Out 
27 
Valve Ph. 4 
Out 


not yet shown the signals from the conveyor speed 
and the liquid flow into the on-board interrupt· 
counters. The schematics show that these signals 
are brought onto the board on the edgeconnectors 
but the locations correspond to Port C lines which 
do not exist on the iCS 930! We have available 
input lines on the Port 1connectors but there is no 
provision to break the signal on the board to route 
it to the counter interrupts. 


If wemove on to the third alternative, wefind that 
the interconnection 
paths 
caused by tieing 


various lines together cause even greater prob- 
lems. Either some fact must have been over- 
looked, or we must consider the use of more than 


Figure 11indicates that three lines are available 
on the Port 2 data lines which go to jumper posts 
and which could be used if they werenot part ofan 
output driver of Port 20. If sometechnique can be 
found to use these "output" lines as inputs, our 
problem will be solved. The use of an open 
collector driver can provide us with the ability to 
use the line as an input so long as the drivers are 
turned off! This should be no problem as we can 
force the outputs to this state either through the 
appropriate jumpering of inputs or by outputting 
data to the OBS 1 ports corresponding to these 
bits. The resulting electrical configuration can be 
seen in Figure 12. 
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Let us examine 
the 'implications 
of performing 


this interconnection. 
The physical 
layout 
of the 


board and the use ofthe terminator/driver 
sockets 


causes the I/O lines to be grouped into sets of four 
data lines. We must choose which of the three iSBC 
941 modules 
will be responsible 
for supporting 


each of the lines. In Figure 12, we can see that the 
belt motor is driven by OBS Socket 1, Bit 20. This 
requirement 
has placed output drivers onto data 


Bits 21, 22 and 23. Our requirement 
is to provide 


two signals 
~hich 
can be routed 
to the counter 


inputs 
so we must place a terminator 
into either 


socket AI0 or A16. We have arbitrarily 
chosen to 


use socket 
AI0. The use of the terminators 
in 


parallel 
with the drivers will not create a problem 


so long as those lines which are used as inputs 


have the driver in the high impedence state. 
This 


is done by requiring 
that the output Bits 21 and 22 


of the 
device 
placed 
into 
socket 
1 are driven 


low. Finally, 
we see that the remaining 
Bit 23 may 


be used 
as 
a general 
purpose 
output 
line if it 


becomes required. 


The 
wiring 
configurations 
for, the 
remammg 


connector 
groupings 
are shown in Figures 
13, 14 


and 
15. In Figure 
13, we see the 
assignments 


which can be used for Bits 10, 11, 12 and 13. We 
have earlier defined that 
an iSBC 941 processor 


would be used in a high speed frequency counting 
mode to determine 
the weigh belt weight. 
This 


device will be placed into socket 2. The use ofthis 
mode precludes 
the use of any general 
purpose 
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input/output operations of the processor if we 
desire to maintain 
maximum accuracy of the 


frequency measurement. 
We will arbitrarily 
choose to use Bit 10 as the location 
of the 


frequency count input. This will necessitate 
installing a terminator into the socketcorrespond· 
ing to the processor input. If required, we can 
install open collectordrivers into socketA14and 
use the remaining three bits for general purpose 
outputs. If this is done, care must be taken to 
assure that Bit 10ofthe devicewhichis placedinto 
socket 3 is placed into a lowstate as was done in 
the preceding example. 


The interconnection scheme for Ports 14through 
17can be seen in Figure 14. Note that no ports of 
this group are dedicated to our defined control 


functions. These four bits may be used as inputs 
or outputs as required by the application. For 
example, we have ignored the fact that actual 
control loops incorporate 
solenoids for flow 


control routing. The unused bits can be used to 
perform these tasks. 


Figure 15 shows the interconnections 
for the 


remaining 
group of bits. There are several 


features shown on this drawing which should be 
discussed in some detail. Let us first consider the 
remaining function which we must implement. 
This is the control for the liquid valve stepper 
motor. An iSBC 941IDP operating in the stepper 
modewill providethe necessary control functions 
to drive the motor. Since all four of this group's 
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data lines are committedto drivethe fourphases of 
the stepper motor, there are no other functions 
available. 


An important feature of the iSBC941 processor is 
illustrated in Figure 12. This is th.e·ability to 
enable the processor to generate an interrupt at 
some point in its operation. We have earlier 
indicated that we willuse the processorin socket2 
(the frequency counter) to provide us with a 200 
msec time reference. When the iSBC 941 proces- 
sor is enabled with an ENFLAG command and is 
operating in the frequency count mode, it will 
generate an interrupt 
on its output line, Port 
25. Figure 15 shows how this interrupt can be 
connected to the hqst board's internal interrupt 
input structures. 
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The hardware configuration has been defined 
through Figure 14. The actual implementation 
can be handled through the use of the various 
wire-wrap jumpers on the 
IDC. Drivers and 


terminators can be installed as indicated in the 
preceding discussion. 


VI. SOFrWARE CONFIGURATION 


As with most computer controlled systems, the 
actual implementation ofthe task is handled with 
software. 
In older' designs and in many mini- 


computer systems, this task has become formid- 
able and has resulted in cost over-runs and 
schedule delays. Intel provides many tools for use 
by the designer to prevent this type ofproblemand 
to assist him in easily creating a workable and well 
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documentedsoftware configuration. Letus lookat 
someofthese toolsin moredetail and consider how 
their use will help us to write our programs easily 
and quickly. 


High Level Programming 
Languages 


A valuable tool, which Intel provides the designer 
of small control systems, is the ability to program 
even the smallest systems using a high level 
programming language, PL/M-80. This language 
offersrelatively efficient and structured, program- 
ming capabilities. It has been determined that 
PL/M-80 users can expect to use between 1.1 to 
slightly more than 2 times as much program 
memory as wouldbeused forthe same task written 
in assembly language. At the same time, the 
programmer's time to codea task willbe consider- 
ably less than ifhe wereto use assembly language. 
The PL/M-80 Programming 
Manual indicates 


that the language is highly structured and lends 
itself very well to handle logical type operations. 
Its weakness in handling complex mathematical 
computations is compensated by the ability to 
combine the user application 
software with 


packaged Intel support software. 


Fundamental Support Packages 
The Intel 8080/8085Fundamental Support Pack- 
age (FSP) provides a package of application 
subroutines and functions which can be called 
from programs written in either assembly lan- 
guage, PL/M-80, or in FORTRAN-80.It uses a 
standard set ofdata structures and a unified status 
and error reporting scheme. Nine major groups of 
operations are fully supported by this package. 
These are: 


1. A primitive fast string handling and integer 


arithmetic capability without error report- 
ing. 
2. A binary integer arithmetic package which 


performs operations on both signed and 
unsigned integers of various lengths in 
binary representation. 
3. The floating-point 
arithmetic 
package 


which provides operations on floating point 
numbers in four formats: single precision, 
single-precision extended, double precision, 
and double-precisionextended. 


4. The decimal arithmetic 
routines which 


perform integer and fixed point computa- 
tions on numbers 
which are stored as 


strings of ASCII characters. 


5. A string handling section which contains 


routines to transform strings and to extract 
and insert substrings. A routine for scan- 
ning ofgeneral input and oneforformatting 
of general output are included. 


6. Routines for number conversion, for numer- 


ic I/O transformation 
of data from one 


format 
to another, 
input 
scanning 
of 


numeric strings, and formatting ofnumeric 
strings for output are also available. 


7. The floating point transcendental function 


section providestrigonometric, exponential, 
and other transcendental functions. 


8. The statistics routines compute the mean, 


variance, and standard deviation of one 
group ofstatistical data, and the covariance 
and correlation factor oftwo groups ofdata. 


9. Finally, the PID proceduresprovidethe user 
with a version ofthe classical Proportional, 
Integral, Derivative control algorithm. 


Clearly, the use of the FSP support programs 
enhance the logical PL/M-80program operations. 


Host/Slave 
Relationship 
Before we proceed with our development, we 
should take sometime to examine the relationship 
between our iSBC 569 IDC and other controllers 
which may be installed 
in the system. 
The 


utilization of intelligent slave boards provides the 
capability 
to develop control concepts to an 


extremely high level if certain guidelines are 
followed. We will therefore 
assume that the 


control solution which we are developing will be 
but a part of an over all control concept which 
utilizes multiple controllers 
sharing 
common 


resources. 
This concept allows us to develop control algo- 
rithms for each sub-process within our overall 
control system. This development can provide 
independent design and implementation of each 
process. A host processor can be used to provide 
any required inter-process communication tasks 
and to provide the operator interface. We have 
previously indicated that the operator interface 
will provide some means to adjust the weighbelt 


feeder setpoints and the liquid ratio. 
It should also 


allow the operator to display the current status of 
the process. 
Since these operator 
interface 
func- 


tions are but a part of the overall control functions, 
the interface 
should 
be programmed 
such that 


maximum 
flexibility 
can be gained 
through 
its 


use. Fortunately, 
such an interface 
is available 


using Intel's 
RMX/80 BASIC-80. 


RMX/SO 
BASIC-SO 
Interpreter 


The RMX/80 BASIC-80 Interpreter 
is a high level 


language 
interpreter 
with extended disk capabili- 


ties. It operates on iSBC 80 Single Board Compu- 
ters 
and allows the interpretation 
of BASIC-80 


source code into an internally 
executable 
form. 
Many 
other 
features 
are available 
and 
many 


configurations 
are possible 
depending 
upon the 


exact system requirements 
(refer to the BASIC-80 


Reference Manual, 9800758). 


Maximum 
utilization 
of the operator 
interface 


with 
a minimum 
of development 
time. can be 


achieved 
with 
the preconfigured 
version 
of the 


software/hardware 
package. 
This will provide us 


with complete disk I/O capabilities 
and the ability 
to easily program 
and maintain 
any programs 


which 
may become necessary 
to implement 
the 


interface. 
The 
actual 
implementation 
of the 


interface 
will be done later, after we have defined 


the control task. 


Software 
Tasks 


The task of preparing 
the software can be broken 


down into three major groupings 
or tasks. 
These 


are defined to be: 


Prepare the Software Drivers. 


This 
involves 
defining 
the 
relationships 


between 
the control 
algorithm 
parameters 


and the input/output 
hardware 
devices and 


creating 
software to implement 
these defini- 


tions. 


Prepare 
the Control Algorithm. 
This 
will 
involve 
developing 
a control 


algorithm 
which 
defines 
the relationships 


between the various system parameters. 
This 


algorithm 
will draw 
heavily 
upon 
the 
re- 


sources 
of the FSP programs 
and the soft- 


ware drivers which relate the parameters 
to 


the physical 
hardware. 


Finally, 
the operator interface 
must be defined 


which will relate the parameters 
used in the 


control scheme to other controllers and to the 
operator. 
This will allow the control task to 


interact 
in such a manner 
as to provide a 


meaningful 
element 
of the overall 
control 


concept. 


VII. 
SOFTWARE 
DRIVERS 


Before developing the actual control algorithm, we 
must create the drivers which communicate 
with 


the three iSBC 941 processors 
in their 
assigned 


operating 
modes. 
We will 
define 
two 
driver 


sections 
for each 
processor, 
one to handle 
the 


initialization, 
and a second to provide the ongoing 


communications 
as 
required 
by the 
control 


algorithm 
program. 


Motor 
Speed 
Control 
Processor 


The first processor which we will discuss is to be 
located in slave socket n umber 0 and will be used to 
produce 
a variable 
frequency 
output. 
Let us 


consider in some detail how this can be accom- 
plished 
using 
an iSBC 
941 Processor. 
First, 


consider the task of initializing 
the device to the 


primary 
function operating 
mode, FREQ. 


Referring 
to the 
iSBC 
941 Industrial 
Digital 


Processor User's Guide, we find that the initializa- 
tion requires the sequence of commands 
and data 


shown in Figure 16. We will identify the meaning 
of each 
of these 
terms 
and 
create 
a software 


Description 
Command/Data 


Request INIT 
C 


FREQ Select 
D 


Scale Factor 
D 


Output Enable 
D 


Initial State 
D 


P20 Delay 
D 


P20 Period 
D 


Request PAUSE 
C 


program which willhandle the required initializa- 
tion of the processor. The purpose and use of the 
various 
commands to the processor are well 


definedin the user's guide and willnot berepeated 
here. 


The first 
byte of data, 
which must be sent 


following the initialization command, is the data 
byte signifying that the operational mode is to be 
the frequency output. This is defined in the 
manual as being equal to the data byte "OB5H"or 
"035H" as expressed in the hexadecimal number- 
ing system. The choice of values to be sent is 
dependent upon our desire to utilizethe internal or 
external time reference period for the operations. 
If we utilize the internal 
time reference, our 


minimum increment or resolution of operations 
will be 86.72microseconds. 


To determine if this speed is adequate for our 
frequency generator, we must consider the impact 
that this resolution has on the output. A 550hertz 
signal has a period of 1.82 milliseconds. If we 
increase this periodby the 86.72microsecondtime 
reference, we find that the next increment in the 
frequencygenerators output willbeapproximately 
372 hertz. This resolution is certainly not ade- 
quate to meet the motor control requirementS! We 
should consider using the external clocktoprovide 
the time reference. One of the 8253 Interval 
Timers on the iSBC 569 board can be used to 
generate a referencetime. If wearbitrarily choose 
to use a 10 microsecond reference to the IDP, we 
find that the worst case resolution forthe 550hertz 
signal becomes about 4 hertz. This is certainly 
within our requirements of motor control. The 
primary function signal should then be sent as a 
"OB5H". 


The second byte is used to establish a scale factor 
for the processor. This scale factor is used to 
generate the basic time increment which can be 
used to establish the frequency output; that is, the 
minimum time increment which can be used to 
establish a period or pulse width will be the scale 
factor times the reference time period. 


In our case, because of the widefrequency output 
range, we cannot specify the scale factor at 
initialization (later data will show the need for 


multiple scale factor ranges). We will then only 
need to send somearbitrary value at initialization 
to allowthe processorto completeits initialization 
sequence. 


The Output Enable data byte is used to select 
which of the Port 2 output bits are to be used to 
generate 
the output 
signals. 
The hardware 


configuration established earlier placedthe output 
onto Bit 0 of the port, so this data byte shall be 
specifiedas a byte having onlyBit 0set to a logical 
one or equal to 01H. 


The Initial Output parameter specifies whether 
each bit selectedas an output by the output enable 
byte is to be initially set to a logical one or zero 
when the processor is first enabled. For this 
application, it really does not matter, but we will 
arbitrarily pick the state to be equal to zero. The 
byte will be defined as being set to DOH. 


The Delay parameter 
is used to define the 


waveform which will be generated and specifies 
the number of time increIl).entswhich must elapse 
before the waveform will change states. Rather 
than to constantly vary the delay to maintain a 
square wave output, we can choose an arbitrary 
value of one time increment before changing 
state. The output willhave a varying duty cycleas 
the frequency changes. This should cause no 
problems for the translator driving the weighbelt 
motor. The byte will be defined as being set to a 
value of 01H. 


Finally, the Period of the waveform must be 
chosen. Again, this parameter will be changed 
according to the desired frequency, so only an 
arbitrary value need be sent. Indeed, since this is 
the last parameter, the value could be omitted 
entirely by sending the PAUSE command in its 
place. 


The initial data definition can be defined using 
PL/M-80 language conventions as a block of six 
bytes as shown in Figure 17. 


The actual communications 
between the host 


processor on the iSBC 569 board and the IDP 
utilizes the protocolexplained in previous sections 
of this note. The status register of the IDP will be 
tested for the bit signifying that the inpnt buffer 


1* DECLARATION 
OF iSSC 941 #0 INITIALIZATION 
DATA 
*1 


DECLARE 
FREQ 
LITERALLY 
'OS5H'; 


DECLARE 
SF 
LITERALLY 
'OOOH'; 


DECLARE 
OUTPUT$ENASLEO 
lITERALL 
Y 'DOl H'; 


DECLARE 
INITIAL$STATE 
lITERALLY'OOOH'; 


DECLARE 
DELAY 
LITERALLY 
'DOl H'; 


DECLARE 
PERIOD 
LITERALLY 
'OOOH'; 


1* DECLARATION 
OF iSSC 941 PRIMARY 
DATA 
*I 


DECLARE 
INIT$0$TASLE(6) 
SYTE DATA 
( 


FREQ, 
SF, 
OUTPUT$ENASLEO, 
INITIAL$STATE, 
DELAY, 
PERIOD 
); 


full is not set. This will indicate that the device is 
ready 
to accept 
either 
a command 
or a data 


byte. The command to request a primary function 
will be sent. At this point, the processor 
will be 


expecting a series of data bytes as specified by the 


function being selected. A "Do Loop" can be used 
to effectively transmit 
this data to the device. The 


program 
to perform this function is illustrated 
in 


Figure 18. 


1* REQUEST 
PRIMARY 
FUNCTION 
*I 
44 
2 
DO WHILE 
( (INPUT 
(UPI$O$STATUS) 
AND 
ISF) < > 0); 
45 
3 
END; 


46 
2 
OUTPUT 
(UPI$O$COMMAND) 
= INITPF; 


1* LOAD 
INITIAL 
PARAMETERS 
*I 


47 
2 
DO 1=0 TO 5; 
48 
3 
DO WHILE 
( (INPUT 
(UPI$O$STATUS) 
AND 
ISF) < > 0); 
49 
4 
END; 
50 
3 
OUTPUT 
(UPI$O$DATA)=INIT$O$TASLE(I); 


51 
3 
END; 


1* TERMINATE 
PARAMETER 
LOADING 
*1 


52 
2 
DO WHILE 
( (INPUT 
(UPI$O$STATUS) 
AND 
ISF) < > 0); 


53 
3 
END; 
54 
2 
OUTPUT 
(UPI$O$COMMAND)=PAUSE; 


1* START 
FREQUENCY 
FUNCTION 
*I 


55 
2 
DO WHILE 
( (INPUT 
UPI$O$STATUS) 
AND 
ISF) < > 0); 
56 
3 
END; 
57 
2 
OUTPUT 
(UPI$O$COMMAND)=LOOP; 


When all required data parameters 
have been sent, 
the data portion of the initialization 
is terminated 


by sending 
a PAUSE 
command 
as shown 
in 


Figure 18. Note how, in each case before data or a 
command 
is sent, we wait until the input buffer is 


empty. 
Finally, 
the initialization 
is completed 


when 
we have 
sent 
the LOOP 
command. 
The 


processor 
will 
now 
be generating 
an output 


frequency 
as specified by the parameters. 


Remember 
that, 
according 
to our earlier 
discus- 


sion and 
as we have 
shown 
in Figure 
12, the 


unused 
output ports should be set to a logical low 


condition to allow the use ofthose lines as inputs to 
carry 
additional 
data 
into 
the 
controller. 
This 


should 
be done 
as a part 
of the initialization 


process. 
The secondary 
utility command, 
CLRP2 
is used for this purpose. 
This process is illustrated 


in Figure 
19. 


We should next direct our attention 
to establishing 


a software 
interface 
which 
will take the desired 


weighbelt speed term and convert it to a frequency 
output suitable 
to drive the motor translator. 
We 


know that this will involve selecting 
a particular 


scale factor and period term which will generate 
the correct waveform. 
Previously, 
we established 


that, 
for a maximum 
frequency 
of 550 hertz, we 


need to establish 
a period 
of 1.82 milliseconds. 


Many 
combinations 
of Scale Factor 
and Period 


parameter 
will generate this time interval. 
Ideally, 


the smallest 
increment 
of change 
can be estab- 


lished by setting 
a constant 
period and modifying 


the scale factor. 
If we make some calculations, 
we 


will find that the fact that the scale factor is a byte 
value 
(giving 
us a range 
of between 
0 and 255) 


limits the frequency range which can be produced 
using anyone 
value for a period. 
It seems that we 


will be forced to vary both the period and the scale 
factor as a function 
of the desired frequency. 


In Figure 20, we have plotted the frequency output 
for various values of Scale Factor and Period. 
Our 


1* SET UNUSED BITS TO ALLOW EXPANSION 
*I 


DO WHILE ( (INPUT UPI$O$STATUS) AND IBF) < > 0); 
END; 
OUTPUT (UPI$0$COMMAND)=CLRP2; 


DO WHILE ( (INPUT (UPI$O$STATUS) AND IBF) < > 0); 
END 
OUTPUT 
(UPI$O$DATA)=INITIAL$OUTPUT; 


Figure 19. Secondary Utility Command 
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intent 
is to maintain 
the 
highest 
resolution 


possible for the desired output range of 50 to 550 
hertz. 
Choosing 
four period base parameters 
will 


provide us with acceptable 
waveform 
generation 


characteristics. 
We will choose the data 
sets of 


Figure 21 based upon the data shown in Figure 20. 


The Period can be determined 
by examining 
the 


desired frequency 
range. 
The scale factor can be 


calculated 
from the equation: 


SF = 10,000 / ( (FREQUENCY) 
x (PERIOD) ) 


Again, the PL/M-80 language 
program 
to imple- 


ment the interface between the host and the IDP is 
easily 
constructed. 
For 
example, 
Figure 
22 


provides 
the' code which 
will ,be required 
to 


determine 
the appropriate 
Period 'parameter 
and 


also illustrates 
the use of FSP programs 
to handle 


the mathematical 
calculations 
required 
to deter- 
mine the corresponding 
scale factor. 


The 
principles 
above 
can 
be expanded 
into 
a 


complete 
interface 
package 
to offload 
the host 


processor 
of the need to generate 
the frequency 


waveform 
to the 
translator 
of the 
weighbelt 


motor. The complete 
program 
for the processor 


can be found in Appendix A. 


Weight 
Input 
Processor 


The second use of an iSBC 941 Processor 
is to 


provide 
the capability 
of converting 
the high 


frequency 
inputs 
from the weight 
sensor 
of the 


weigh belt into a digital 
value equivalent 
to the 


actual weight on the belt. This frequency to digital 
conversion' can be easily accomplished 
by the use 


of the Primary 
Function, 
FCOUNT. 


Frequency 
'Period 
Scale Factor 
Resolution 


50 to 165 Hz. 
9 
221 to 67 
3 Hz. 


166 to 225 Hz 
5 
121 to 89 
3 Hz. 
226 to 285 Hz. 
3 
147 to 117 
3 Hz. 
286 to 550 Hz. 
2 
175 to 91 
6 Hz. 
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/* COMPUTATION 
OF FREQUENCY RANGE *1 


IF FREQ < 285 
THEN DO; 
IF FREQ < 226 
THEN DO; 


IF FREQ < 166 
THEN RANGE = 9; 
ELSE RANGE = 5; 
END; 
ELSE RANGE = 3; 


END; 
ELSE RANGE = 2; 


1* LOAD MATH ACCUMULATOR 
WITH 100,000 *1 


CALL MQULD4 (.IR,.HUNDRED$K); 


1* TEST FOR MOTOR SHUTDOWN 
*1 


IF FREQ >1 
THEN DO; 


1* DIVIDE BY FREQUENCY 
*1 


CALL MQUDV2 (.IR,.FREQ); 


1* DIVIDE BY RANGE FACTOR 
*1 


CALL MQUDV1 (.IR,.RANGE); 


1* GET TWO'S COMPLEMENT 
FOR iSBC 941 SCALE FACTOR 
*1 


CALL MQUST1 (.IR,.FREQA); 
FREQA=NOT 
(FREQA + 1); 


END; 


The FCOUNT 
Primary 
Function 
is selected 
by 


sending 
the INITPF 
command 
followed by four 


parameters. 
The process is identical 
to that which 


was 
used 
in the 
previous 
example 
when 
we 


eS,tablished the FREQ function. 
In this case, the 


sequence is described in the manual 
as is shown in 


Figure 23. 


Description 
Command/Data 


Request INIT 
C 


Select FCOUNT 
D 


Input Select 
D 


Output Enable 
D 


Sampling 
Interval 
D 


Request PAUSE 
C 


Let us examine 
the derivation 
of the terms which 


must 
make 
up the 
data 
table 
which 
will 
be 


transmitted 
to the processor in order to initialize 


it. The FCOUNT 
function 
does not allow the use 


of an external 
clock so we have no option as to 


which 
command 
will 
be sent 
to select 
this 


function. 
It is defined 
to be equal to 33H. This 


becomes the first element of the byte array used to 
contain 
the initial 
data. 


The Input Select parameter 
describes which of the 


Port 
1 inputs 
are to be measured. 
If we refer to 


Figure 13, we can see that a hardware 
assignment 


of Port 10 has been made for this function. 
This 


assignment 
corresponds 
to bit 0 of the parameter 


being set to a value of 1. The byte value for this 
parameter 
then becomes OlH. 


The Output Enable byte is used to enable an output 
port corresponding 
with the input to change states 


when the Sampling 
Interval 
time has elapsed. Our 


system 
has 
a requirement 
to operate 
the control 


algorithm 
once each 200 milliseconds 
and we have 


previously 
indicated 
that 
the frequency 
counter 


would be used to establish this time interval. 
If the 


output 
is enabled 
and connected 
to an interrupt 


line, it will provide our system with the required 
pacer clock. The output bit from Port 20 will then 
be enabled 
to provide 
the interrupt. 
The para- 


meter for this byte will be set to the same value as 
the Input Select and becomes 01H. 


The 
Sampling 
Interval 
will establish 
the time 


interval 
to be used 
when 
sampling 
the 
input 


frequency. 
This time interval 
should be set to 200 


milliseconds 
for our application. 
The parameter 
is 
then calculated 
from the equation: 


INTERVAL 
= (SAMPLE PERIOD) 
/ (0.02222) 


OR 
INTERVAL = (0.200) / (0.02222) = 9 


The 
correct 
sampling 
interval 
for our control 


system should be set to a value of 09H. 


A similar procedure can be used to send this data 
to the processor. 
The actual 
code used to imple- 


ment 
the 
system 
can 
be found 
in Appendix 


A. Note that 
the unused 
bits of the device have 


been set to a predetermined 
value as was indicated 


by our hardware 
design of Figure 13. 


Once the 
processor 
has 
been 
initiated 
and 
is 


performing 
its function, 
we need only wait until 


the device signals us that the 200 millisecond time 
interval 
has passed 
and that it is ready with the 


belt weight. 
When this interrupt 
occurs, we will 


read the data and perform our control functions. 
An interface 
must 
be established 
between 
the 


control 
algorithm 
and 
the 
processor 
which 


enables it to receive a value which represents 
the 


actual weight. 


The 
total 
count 
received 
by the 
processor 
is 


available 
as a sixteen 
bit count made up of two 


eight bit bytes. 
The use of the Secondary 
Utility 


Commands, 
Read 
FCOUNT 
Measurements 
(RDFCO-RDFCF) 
allow 
the 
two 
bytes 
to be 


transferred 
into the host processor. 
We are using 


the first counter so we will use the corresponding 
commands, 
RDFCO and RDFC1. 
An example 
of 


the procedure to read one ofthe count bytes can be 
seen in Figure 24. 


The counter can be commanded 
to begin its next 


sample period by issuing a LOOP command to the 
processor. 
The two data bytes can be combined to 


form a 16-bit word and the resultant 
value divided 


by 2 to form a weight value. 
The division by two to 


obtain 
weight 
is required 
since the count range 


from 0to 2000 corresponds 
to a weight of between 0 


and 10.00 pounds; thus, each count has a value of 
0.005 pounds. 
The integer 
numbers 
used in the 
control algorithm 
are fixed point with an implied 


scale factor of 100. The division by two provides a 
result which meets the criteria. 


/* GET INPUT COUNT 
LOW BYTE */ 


DO WHILE 
( (INPUT 
(UPI$l$STATUS) 
AND 
IBF) < > 0); 


END; 
OUTPUT 
(UPI$l$COMMANO) 
= ROFCO; 


DO WHILE 
( (INPUT$l$STATUS) 
AND OBF) = 0); 


END; 
LCOUNT 
= INPUT 
(UPI$l$OATA); 
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Appendix 
A provides the complete listing 
of the 


code 
which 
was 
used 
to interface 
with 
the 


processor 
assigned 
to the 
primary 
function, 
FCOUNT. 
Stepper Motor Control Processor 


The 
third 
example 
of utilizing 
the 
iSBC 
941 


Processor in an industrial 
application 
is provided 


by the processor installed 
into OBS socket 2. This 


device is used to drive a stepper motor which, in 
turn, controls the liquid valve position. 
Again, we 


will break the discussion into an initialization 
and 


an interface 
operational 
mode. 


We find 
that 
the User's 
Guide 
indicates 
that 
initialization 
to the STEPPER 
Primary 
Function 


is performed 
by sending 
the 
IN IT command 


followed 
by up to 21 data 
bytes. 
Figure 
25 
provides 
the table 
which 
shows 
the necessary 
parameters 
for this mode. 


The technique 
used to place the processor into the 
desired function is the same as we have seen with 
the two other processors so we will not spend time 
dealing 
with the communications 
sequence. 
In- 


stead, we will examine the techniques 
which can 


be used to determine 
the values of the initializa- 


tion parameter 
bytes. 


STEPPER 
is requested 
by sending a data byte of 
either 17H or 97H following the INIT command. 
Remember that the significance 
of setting bit 7 of 


the data high is to request that an external 
clock 


be used by the processor. 
There is no reason to use 


an external 
clock for our application, 
so we can 


choose a function 
request byte of 17H. 


The remainder 
of the data- is used to define the 


waveforms 
which 
are 
necessary 
to drive 
the 


stepper motor. We will derive the values for these 
parameters 
by beginning 
with the manufacturer's 


data sheet and moving until we have determined 
the correct value for each byte of data. 


The motor chosen for this application 
utilizes four 


phases to drive the shaft. The data sheet provided 


Description 
Command/Data 


Request 
INIT 
C 
Select STEPPER 
0 
Select Scale Factor 
0 


Output 
Enable 
0 


Output 
Polarity 
0 


Common 
Period 
0 


P20TRANl 
0 


P20TRAN2 
0 


P21TRANl 
0 


P21TRAN2 
0 


P22TRANl 
0 


P22TRAN2 
0 


P23TRANl 
0 


P23TRAN2 
0 


P24TRANl 
0 


P24TRAN2 
0 
P25TRANl 
0 


P25TRAN2 
0 


P26TRANl 
0 


P26TRAN2 
0 


P27TRANl 
0 


P27TRAN2 
0 


Request 
PAUSE 
C 


information 
for both a Four-Step Input Sequence 
(1.8 degrees per step) and for an Eight-Step 
Input 


Sequence (0.9 degrees per step). We will use the 1.8 
degree step angles 
for our example 
and applica- 


tion. The data 
provided 
by the manufacturer 
is 


shown in Figure 26. The first task is to convert the 
switch state diagram 
into a desired waveform for 
each of the four phases. 
This has been done in 


Figure 27. 


Beginning 
with Scale Factor, let us determine the 


required 
data 
parameters 
which 
will 
yield 
a 


stepper controller compatible with our motor. The 
Scale 
Factor 
will provide 
the 
minimum 
time 


period for one step to take place. The minimum 
time which we can specify is a function of both the 
motor 
characteristics 
and 
of the TRP for the 


primary 
function, STEPPER. 
The minimum TRP 


is determined 
by referencing 
the IDP User's Guide 


for the desired function. 
In this case, it is found to 


be 325 + (13 x B) where B is the number of phases 


STEP 
SWl 
SW2 
SW3 
SW4 


1 
ON 
OFF 
ON 
OFF 


2 
ON 
OFF 
OFF 
ON 


3 
OFF 
ON 
OFF 
ON 


4 
OFF 
ON 
ON 
OFF 


5 
ON 
OFF 
ON 
OFF 


STEP 
SWl 
SW2 
SW3 
SW4 


1 
ON 
OFF 
ON 
OFF 


2 
ON 
OFF 
OFF 
OFF 


3 
ON 
OFF 
OFF 
ON 


4 
OFF 
OFF 
OFF 
ON 


5 
OFF 
ON 
OFF 
ON 


6 
OFF 
ON 
OFF 
OFF 


7 
OFF 
ON 
ON 
OFF 


8 
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OFF 
ON 
OFF 


1 
ON 
OFF 
ON 
OFF 
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which are used. The result will be expressed 
in 


terms 
of processor 
cycles and can be converted 


into time by multiplying 
by 2.71 microseconds 
per 


cycle. This works out to be: 


325 + (13 x 4) = 377 PROCESSOR 
CYCLES 
OR 


377 x 2.71 = 1.021 MILLISECONDS 


Now, let's examine the minimum time which can 
be utilized by the stepper motor. This is given in 
the manufactuer's 
data sheets as being 2.86 milli- 
seconds for the motor which we have chosen to 


use. This value must be used to compute the Scale 
Factor 
for this application. 
The Scale Factor 
is 


computed by dividing the minimum 
step time by 


86.72 microseconds 
or: 


SF=2.86 MILLISECONDS/86.72 
MICROSECONDS=33 


This number 
is entered into the processor 
using 


two's complement which becomes equal to ODFR. 


The Output Enable is used to specify which of the 
eight possible 
control 
outputs 
are to be used to 


control 
the 
motor 
phases. 
The 
motor 
phase 


assignments 
to 110 ports was made in Figure 15 


and indicates 
that 
Ports 
24 through 
27 will be 


enabled 
for the primary 
function. 
Setting 
the 


corresponding 
bits provides a parameter 
to be sent 


to the processor of OFOR. 


The rest of the parameters 
deal with providing 
a 


definition ofthe waveforms generated in Figure 26 
to the processor. 
The following paragraphs 
deal 


with 
the 
operations 
required 
to convert 
the 


graphic representation 
into data parameters. 


Each phase must be initialized to an initial output 
state which corresponds 
to the signal level shown 


for Step 0 of Figure 27. A "1" will be placed into 
the bit corresponding 
to each of the port's output 


bits which are to be in a logical one state upon 


reaching 
step O. We see that Bits 24 and 26 are set 


corresponding 
to phase I and 3. The data byte for 


Initial 
Output is thus defined to be 050H. 


The Period parameter 
for a stepper motor function 


corresponds 
to the 
number 
of steps 
which 
are 


defined in the motor's step sequence. 
Our example 


uses a four step sequence so the Common Period 
will be set to a value of 04H. 


The remainder 
of the initialization 
parameters 


define the transitions 
of each of the phases. 
This 


involves 
the examination 
of the waveform 
and 


noting 
the 
points 
at 
which 
the 
output 
level 


changes. 
This 
data 
can 
be input 
to allow the 


device to accurately 
produce 
the control 
wave- 


forms for any stepper motor control mode. We are 
not using the first four output bits so the transition 
definitions 
for these outputs 
is meaningless 
and 


will be output as zeroes. The waveform for output 
Port 24 shows a transition 
at steps I and 3. The 


parameter 
for the 
first 
transition 
of Port 
24, 
P24TRANI 
is defined 
to be OOH. Likewise, 
the 


second transition, 
P24TRAN2 is set to a value of 


02H. 


The technique 
used above can be continued 
to 


define the constants, 
P25TRANI 
and P25TRAN2 


as being the same as for Port 24 or OOHand 02H 
respecti vely. 


The transitions 
for the phases driven from Port 26 


and 27 can be seen to occur at steps I and 3 so the 
data for those parameters 
can easily be seen to be 


set to OIH and 03H for each port. 


The 
initialization 
table 
can 
be sent 
to the 


processor using the same techniques 
as were used 


for the processors 
discussed 
previously. 
The 


complete 
program 
for the initialization 
can be 


found in Appendix 
A. 


A driver must next be prepared which will be used 
to provide 
the 
interface 
between 
the 
control 


algorithm 
and the IDP processor which supports 


the stepper motor. When the STEPPER 
primary 


function is used, a queue is utilized for supporting 
the step commands 
to the motor. 
Each command 


to the stepper consists of a data byte signifying 
the 


step rate to be used and a data byte which provides 
the signed magnitude 
of the number of steps to be 


moved. Using the motor to control a flow control 
valve allows us to use a constant 
step rate, but 


some type of program must be prepared which will 
convert the signed two's complement 
representa- 


tion ofthe position from the control algorithm 
to a 


signed magnitude 
format. 


The number 
conversion 
is easily 
done and the 


PLIM-80 programming 
code to perform the format 


change 
is shown in Figure 28. 


The 
data 
queue 
allows 
up to six movement 
commands 
to be present 
and 
waiting 
to be 


serviced by the IDP. If the processor is behind in 
its 
operations 
and 
cannot 
accept 
a seventh 


request, 
the 
host 
must 
wait 
until 
one 
of the 


requests 
in the 
queue 
has 
been serviced. 
The 


queue status bits can be tested to determine if room 
exists for another 
command 
and the "queue not 


empty" 
bit 
can 
be tested 
to verify 
that 
all 


requested 
movements 
have 
been 
completed. 


Normal operation of our motor should be such that 
the queue is not allowed to fill to its maximum 
capacity. 


1* SUPPORT 
CONVERSION 
TO SIGNED 
MAGNITUDE 
NUMBER 
*I 


IF POSITION> 
127 
THEN 
DO; 


1* GET MAGNITUDE 
OF MOVEMENT 
*1 


POSITION 
= 256 - POSITION; 


1* SET SIGN 
FOR CCW ROTATION 
*1 


POSITION 
= POSITION 
OR REVERSE; 


END; 


The code which is required to test the queue and to 
send 
a stepper 
movement 
request 
is· shown 
in 


Figure 
29. The complete 
code can 
be seen 
in 


Appendix A. 


VIII. APPLICATION 
SOFTWARE 


Having 
developed the software which is required 


to support 
the Industrial 
Digital 
Processors, 
we 


can now devote our time to the task of implement- 
ing the application 
software and of handling 
any 


programs 
which are required to support functions 


unique to the host iSBC 569 board. 
This software 


can 'be 
grouped 
into 
two general 
categories, 
initialization 
programs, 
and 
control 
algorithm 


programs. 


Initialization Progra~s 


The initialization 
ofthe iSBC 569 involves setting 


up the required 
configuration 
of interrupt 
hand- 


ling and of the devices which are installed into the 
slave sockets. 
For the purposes 
of this applica- 


tion, 
we will include 
some system 
diagnostic 


capabilities 
within 
the process. These 
routines 


will be executed each time a RESET or a POWER- 
UP occurs. Only the highlights 
of the code used 


will be'presented 
in detail; however, the complete 


listings 
of the initialization 
programs 
can be 


found in Appendix A by referring to the BCKGND 
Program 
listing. 


A unique feature of using the iSBC 941 processors 
is their 
ability 
to provide, 
upon 
request,' 
an 


identification 
code. The 
initiation 
diagnostic 


program 
takes advantage 
of this fact by interro- 


gating 
each 
processor 
and 
verifying 
that 
the 


correct ID code is returned. 
If any of the proces- 


sors have failed catastrophically 
or if the internal 


data bus of the host board has failed, the program 
will provide an indication 
of this fact. 


Each of the slave processors has, associated 
with 


it, an individual 
hardware 
reset 
line which 
is 


under the control of t}{ehost. A reset or power up 
condition will cause the control lines to reset to the 
state which hold each slave'in a reset state. 
Before 


any slave can be used, it's associated 
reset line 


must be de-activated. 
This is done by sending 
a 


logical one to the corresponding 
bit of the Reset 


Latch. 
Other bits of the Reset Latch can be used to 


illuminate 
the on-board 
LED or to generate 
an 


interrupt 
to another 
boa~d on the Multibus 
data 


bus. 


A special PL/M-80 command is utilized to disable 
the reset interrupts 
of the 8085A host processor. 


Execution 
of this command 
will allow all servic- 


able interrupts 
to enter via the 8259A Interrupt 


Controller. 
The command which will mask off the 
unused interrupt 
structure 
is shown in Figure 30. 


, 
. 


The initialization 
process must also initialize 
the 


FSP Integer Record. This will allow the use of the 
math 
support routines 
which will be required 
to 


support the control algorithm. 


1* VERIFY THAT QUEUE SPACE IS AVAILABLE 
*1 


DO WHILE ( (INPUT (UPI$2$STATUS) 
AND QF) < > 0); 


END; 


1* REQUEST DESIRED STEP RATE *1 


DO WHILE ( (INPUT (UPI$2$STATUS) 
AND IBF) < > 0); 


END' 
OUT'PUT (UPI$2$DATA) 
; 
STEP$RATE; 


1* REQUEST STEPPER MOVEMENT 
*I 


DO WHILE ( (INPUT (UPI$2$STATUS) 
AND IBF) < > 0); 


END; 
OUTPUT 
(UPI$DATA) 
; 
POSITION; 
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3 
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4 
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3 


151 
3 
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153 
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1* MASK OUT THE RESET INTERRUPTS OF THE PROCESSOR 
*I 


CALL S$MASK (MASKS); 


Control Algorithm Programs 
The program which actually handles the control 
algorithm 
for the two loops can be found in 


Appendix A, MAIN$CONTROL. The flow of the 
program is straightforward 
and can easily be 


followed by reading the listing. The operations 
are primarily handled by the use ofrepeated calls 
to the FSP integer math routines and to the 
processor 
interface 
modules which we have 


previously generated. 


It is beyond the scope of this application note to 
dwell upon the techniques which were used to 
generate the PID control routine; this aspect will 
be covered in a future application note. 


Limits were placed upon the control outputs so 
that the signals to the processors wouldnot exceed 
the physical limits of the external devices. For 
example, the frequency range is limited to range 
between 
0 and 550 to correspond 
with the 


operating 
range of the weighbelt as we have 


defined it. The limits upon the liquid control valve 
have been set at plus and minus 10steps since this 
is the maximum distance which the stepper motor 
can travel in anyone 200millisecond time period; 
increasing the possible count couldresult in filling 
the queue. This could cause the 200 millisecond 
time to be extended if wehad to wait for the queue 
to empty. 


Master Processor 
A completecontrol solution tothe weighbelt feeder 
and the liquid applicator has now been developed. 
The process is stand alone and resides entirely 
upon a single board. It can operate without 
requiring any access from the MULTIBUS bus, 
thus freeing the bus for other control, monitoring 
or supervisory duties. 
The system developed for this application note 
requires a setpoint for the mass flow and a liquid 
ratio be provided to the control system. This 
information would normally be supplied by some 
type of bus master device. Wehave chosen to use 
the pre-configured RMX/80 BASIC-80Interpreter 
to perform this task. A simple program needs to 
be prepared which will allow adjustment of the 
setpoints and monitoring of the operation of the 
control system. 
Using BASIC will provide full disk I/O capabil- 
ities to the operator. Communicating with the 


system through a CRT terminal, he can write and 
execute programs which use the resources of the 
system disk or of any ofthe controllers which may 
be present on the bus. 
Two programs 
are required 
to perform 
this 


task. Since they are written in BASIC, they may 
easily be modified or expanded if the need should 
ever arise. 
Indeed, other programs 
could be 


written to perform other tasks, such as optimizing 
the control parameters. 
In both programs, the parameters involved with 
the control operation are accessed by using the 
PEEK and POKE instructions. Remember that 
the iSBC 569 controller 
allows the o~:qoard 


memory to be made available to other devices on 
the bus through the dual port mechanism. In our 
application, this has been done by jumpering the 
board such that the on-board memory beginning 
at location 8000H can be accessed on the bus at 
location 2000H. This mapping was done since the 
niemory locations at 2000Hare not used by BASIC 
unless requested to do so. A byte of data which is 
at location 827EH on the controller can be read py 
performing a PEEK of location 227EH. Some of 
the memory assignments for the controller have 
been shown in Figure 31. 


829 
FH 
8233 
H 
825 
F H 
OODCH 
OOE 6H 
827 A H 
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SYM 
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SYM 
LlOUIDFLOW 
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DISTREV 
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SYM 
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SYM 
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SYM 
BEL TSPEED 


SYM 
MASSSETPOINT 


SYM 
CONVLENGTH 


SYM 
BELTCONTROL 


SYM 
SYSTEMRUNNING 


SYM 
ICW 


SYM 
JUMPTABLE 


SYM 
PRCV 


SYM 
BELTCOUNT 


SYM 
BOUNDS1 


SYM 
CONTROL2 


SYM 
BEL TWEIGHT 


SYM 
SETPOINT 


SYM 
SIX 


SYM 
LlOUIDRATIO 


SYM 
ERRORFIELD 


SYM 
THOUSAND 
SYM 
INITIATION 


10 REM THIS PROGRAM IS USED TO INPUT SETPOINTS 
15 REM TO THE LIQUID CONTROL SYSTEM. 
20 POKE 02287H,0 
25 INPUT "ENTER MASS SETPOINT-";MS 
26 IF MS > 1200 THEN 25 
30 MS=CINT(MSx10/60) 
35 H=INT(MS/256) 
40 L=CINT(MS-Hx256) 
45 POKE 0227EH,L 
50 POKE 0227FH,H 
55 INPUT "PERCENT lIQUID-";LR 
60 LR=CINT(LR) 
65 IF LR > 127 THEN 55 
70 POKE 02284H,LR 
75 POKE 02287H,1 
80 RUN "STATUS" 


Upon completion 
of the initialization 
program, 
a 


second program 
provides a display 
of the system 


operation. 
This 
program 
could 
have 
been 
an 


optional 
program 
which is only called when the 


operator 
desires to view the system operation. 
A 


program which provides a snapshot 
of the system 


operation 
is shown 
in Figure 
33. Again, 
the 


program 
is interactive 
with the operator 
and can 


easily 
be modified 
at any 
time. to reformat 
or 


display 
additional 
information. 


The first 
program 
involves 
setting 
up the two 


control parameters 
and handling 
the control flag 


which causes the process to start and to stop. This 
program 
can be found in Figure 32. 


IX. CONCLUSION 


The purpose of this application 
note has been to 


demonstrate 
some of the techniques 
which can be 


used to provide a control system design solution 
using an intelligent 
slave concept. 
This has been 


done and the system has been constructed 
and has 


been found to operate as the design specified. 
The 


Intelligent 
Slave 
Concept does provide 
a single 


board solution to distl:ibuted control and certainly 
off-loads the master 
processor 
of control 
duties. 


10 I=PEEK(0227EH) 
20 H=PEEK(0227FH) 
30 MS=(256xH)+L)x60/10 
40 L=PEEK (02278H) 
50 H=PEEK(02279H) 
60 WT=«256xH)+L)/100 
70 L=PEEK(022890H) 
80 H=PEEK(02281H) 
90 AM=«256xH)+L)x60/10 
100 MT=PEEK(02294H) 
110 LR=(PEEK(02284H))/100 
120 LS=AMxLR 
130 L=PEEK(0227AH) 
140 H=PEEK(0227BH) 
150 LF=«(256xH)+L)/100 
160 PRINT "MASS SETPOINT","WEIGHT","ACTUAL 
MASS","MOTION" 
170 PRINT MS.WT,AM,MT 
180 PRINT "LIQUID 
RATIO","lIQUID 
SET","lIQUID 
FLOW" 


190 PRINT LR,LS,LF 
200 Z=PEEK(02285H) 
210 IF Z < 128 THEN 230 
220 Z=256-Z 
225 Z=O-Z 
230 L=PEEK(02282H) 
231 H=PEEK(02283H) 
232 BS=«(256xH)+L)x60/200 
239 PRINT "STEPPER";Z, "BEL T";BS 
240 PRINT"" 
250 PRINT"" 
260 FOR N=O to 1000 
270 NEXT N 
280 GO TO 10 


This 
frees 
the 
master 
to provide 
supervisory 


control and human 
interface 
duties. 


Certainly, 
this 
concept 
can 
be expanded 
to 


encompass 
a broad 
variety 
of complex control 


situations. 
At the same time, there is no reason 


why the Intelligent 
Slave board could not be used 


to provide 
a single 
board 
solution 
to a simple 


control 
application 
where 
no interaction 
with 


other processes is required. 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF MODULE 
BACKGROUNDMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:F1:BCKGND.OBJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:F1:BCKGND.PLM 
DEBUG 
PAGEWIDTH(72) 
TITLE('BA 
-CKGROUND 
PROGRAM') 


/****************************************** 
* THIS 
IS THE 
MAIN 
BACKGROUND 
OPERATING 
* 


* 
PROGRAM 
FOR 
THE 
PID CONTROL 
SYSTEM. 
* 


******************************************/ 


/* DECLARATION 
OF BOARD 
I/O 


DECLARE 
UPI$0$STATUS 


DECLARE 
UPI$l$STATUS 


DECLARE 
UPI$2$STATUS 


ASSIGNMENTS 
*/ 
LITERALLY 
LITERALLY 
LITERALLY 


'0E5H'; 
'0E7H'; 
'0E9H' ; 


DECLARE 
UPI$0$COMMAND 


DECLARE 
UPI$l$COMMAND 


DECLARE 
UPI$2$COMMAND 


LITERALLY 
'0E5H'; 


LITERALLY 
'0E7H'; 


LITERALLY 
'0E9H'; 


DECLARE 
UPI$0$DATA 


DECLARE 
UPI$l$DATA 
DECLARE 
UPI$2$DATA 


LITERALLY 
'0E4H'; 


LITERALLY 
'0E6H'; 


LITERALLY 
'~E8H'; 


/* DECLARATION 
OF RAM 
TEST 


DECLARE 
BEGIN$RAM 


DECLARE 
END$RAM 


DECLARE 
ZERO$PATTERN 


DECLARE 
ONES$PATTERN 


PARAMETERS 
*/ 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 


'8000H'; 
'8500H'; 
'000H'; 
,0FFH '; 


/* DECLARATION 
OF RESET 


DECLARE 
RESET$UPI$0 
DECLARE 
RESET$UPI$l 
DECLARE 
RESET$UPI$2 
DECLARE 
LIGHT$LED 


DECLARE 
MULTI$INTR 


LATCH 
BIT ASSIGNMENTS 
*/ 


LITERALLY 
'000000018'; 


LITERALLY 
'00000010B'; 


LITERALLY 
'00000100B'; 


LITERALLY 
'00001000B'; 


LITERALLY 
'00010000B'; 


/* 
DECLARATION 
OF 
ISBC 
941 
STATUS 
BITS 
*/ 


DECLARE 
IBF 
LITERALLY 
'00000010B'; 


DECLARE 
OBF 
LITERALLY 
'00000001B'; 


/* 
DECLARATION 
OF 
ISBC 
941 
COMMANDS 
*/ 


DECLARE 
IDEN 
LITERALLY 
'000H'; 


/* DECLARATION 
OF 
ISBC 
941 
IDENTIFICATION 
CODE 
*/ 


DECLARE 
SBC941 
LITERALLY 
'41H'; 


/* 
DECLARATION 
OF MEMORY 
TEST 
ADDRESS 
REGISTER 
*/ 


DECLARE 
I ADDRESS 
AT 
(87FEH); 
DECLARE 
MEMLOC 
BASED 
I BYTE; 


DECLARE 
MASKS 
BYTE 
DATA 
(00FH); 


/* DECLARATION 
OF PL/M-80 
SIM 
INSTRUCTION 
*/ 


S$MASK: 
PROCEDURE 
(MASK) 
EXTERNAL; 
DECLARE 
MASK 
BYTE; 
END 
S$MASK; 


/* DECLARATION 
OF 
INITIATION 
TASK 
*/ 


INITIATION: 
PROCEDURE 
EXTERNAL; 
END 
INITIATION; 


/* 
CLEAR 
ISBC 
941 DEVICES 
USING 
ON-BOARD 
RESET 
*/ 


OUTPUT 
(RESET$LATCH$ADR) 
= 
0; 


/* MASK 
OUT 
THE 
RESET 
INTERRUPTS 
OF THE 
PROCESSOR 
*/ 


CALL 
S$MASK 
(MASKS); 


/* TEST 
MEMORY 
RAM 
LOCATIONS 
*/ 


DO 
I = BEGIN$RAM 
TO 
END$RAM; 
MEMLOC 
= ZERO$PATTERN; 
DO WHILE 
MEMLOC 
<> 
ZERO$PATTERN; 
END; 


MEMLOC 
= ONES$PATTERN; 
DO WHILE 
MEMLOC 
<> 
ONES$PATTERN; 
END; 
END; 


/* RELEASE 
941 
LOCKOUT/RESET 
OUTPUT 
(RESET$LATCH$ADR) 
BITS 
*/ 


RESET$UPI$0 
OR 


RESET$UPI$l 
OR 


RESET$UPI$2 
OR 


MULTI$INTR; 


/* VERIFY 
THAT 
SBC941 
PROCESSOR 
IS IN SOCKET 
0 */ 


DO WHILE 
«INPUT 
(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT 
(UPI$0$COMMAND) 
= IDEN; 
DO WHILE 
«INPUT 
(UPI$0$STATUS) 
AND 
OBF) 
0); 
END; 
DO WHILE 
(INPUT 
(UPI$0$DATA) 
<> 
SBC941)j 
ENDj 


/* VERIFY 
THAT 
SBC941 
PROCESSOR 
IS IN SOCKET 
1 */ 


DO WHILE 
«INPUT 
(UPI$l$STATUS) 
AND 
IBF) 
<> 
0)j 
ENDj 
OUTPUT 
(UPI$l$COMMAND) 
= 
IDENj 
DO WHILE 
«INPUT 
(UPI$l$STATUS) 
AND 
OBF) 
0)j 
ENDj 
DO WHILE 
(INPUT 
(UPI$l$DATA) 
<> 
SBC941); 
ENDj 


/* VERIFY 
THAT 
SBC941 
PROCESSOR 
IS IN SOCKET 
2 */ 


DO WHILE 
«INPUT 
(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT 
(UPI$2$COMMAND) 
= IDEN; 
DO WHILE 
«INPUT. 
(UPI$2$STATUS) 
AND 
OBF) 
0); 


END; 
DO WHILE 
(INPUT 
(UPI$2$DATA) 
<> 
SBC941); 


END; 


/* 
START-UP 
TEST 
OK- 
TURN 
OFF 
LED 
*/ 
OUTPUT 
(RESET$LATCH$ADR) 
= RESET$UPI$0 
OR 


RESET$UPI$1 
OR 


RESE'l'$UPI$2OR 
LIGHT$LED 
OR 


MULTI$INTR; 


/* INITIATE 
THE 
CONTROL 
DEVICES 
*/ 


CALL 
INITIATION; 


/* 
PERFORM 
BACKGROUND 
TASKS 
*/ 
DO WHILE 
1; 
HALT; 
END; 


= 00D4H 


0000H 
0002H 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 
128 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


END 
OF PL/M-80 
COMPILATION 


212D 


0D 
2D 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF MODULE 
MAINCONTROLMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:Fl:CNTTSK.OBJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:Fl:CNTTSK.PLM 
DEBUG 


$INTVECTO~(4,3F00H) 
$PAGEWIDTH(72) 
$TITLE('MAIN 
CONTROL') 


/**************************************************** 
* 
MAIN$CONTROL$TASK 
* 
* 
THIS 
TASK 
IS USED 
TO CONTROL 
THE 
TWO 
PID CONTROL 
* 
* 
LOOPS. 
ONE 
LOOP 
CONTROLS 
THE 
SPEED 
OF A CONVEYOR 
* 


* WHILE 
THE 
SECOND 
CONTROLS 
THE 
FLOW 
OF A 
LIQUID. 
* 
* THE 
TASK 
OPERATES 
EACH 
200 MSEC. 
* 
* 
* 
******** VERSION 
1.1 *******************************/ 


/* DECLARATION 
OF PID 
RECORD 
SET-UP 
TASK 
*/ 
UQPSET: 
PROCEDURE 
(PR$PTR,ERRORSFLD$PTR,PRIV$PTR) 
EXTERNAL 


DECLARE 
(PR$PTR,ERROR$FLD$PTR,PRIV$PTR) 
ADDRESS; 


END 
UQPSET; 


/* DECLARATION 
OF 
PID 
CONTROL 
BITS 
*/ 
UQPSCT: 
PROCEDURE 
(PR$PTR,CONTROL$PTR) 
EXTERNAL; 


DECLARE 
(PR$PTR,CONTROL$PTR) 
ADDRESS; 
END 
UQPSCT; 


/* PROCEDURE 
TO 
SET 
UP PID 
CONSTANTS 
*/ 
UQPSCN: 
PROCEDURE 
(PR$PTR,CONSTANT$PTR) 
EXTERNAL; 
DECLARE 
(PR$PTR,CONSTANT$PTR) 
ADDRESS; 
END 
UQPSCN; 


/* DEFINE 
THE 
DEFAULT 
ERROR 
HANDLER 
*/ 
UQPSBD: 
PROCEDURE 
(PR$PTR,BOUND$PTR) 
EXTERNAL; 
DECLARE 
(PR$PTR,BOUND$PTR) 
ADDRESS; 
END 
UQPSBD; 


/* PROCEDURE 
TO 
CHANGE 
THE 
TIME 
INTERVAL 
*/ 
UQPSTI: 
PROCEDURE 
(PR$PTR,TIME$INTERVAL$PTR) 
EXTERNAL; 


DECLARE 
(PR$PTR,TIME$INTERVAL$PTR) 
ADDRESS; 


END 
UQPSTI; 


/* DECLARATION 
OF THE 
PID CONTROL 
PROGRAM 
*/ 


UQPPID: 
PROCEDURE 
(PR$PTR,IR$PTR) 
EXTERNAL; 
DECLARE 
(PR$PTR,IR$PTR) 
ADDRESS; 
END 
UQPPID; 


/* DECLARATION 
OF WEIGHBELT 
SPEED 
INTERFACE 
*/ 


WEIGHBELT$SPEED: 
PROCEDURE 
BYTE 
EXTERNAL; 
END WEIGHBELT$SPEED; 


/* DECLARATION 
OF WEIGHBELT 
WEIGHT 
INTERFACE 
*/ 


WEIGHBELT$WEIGHT: 
PROCEDURE 
ADDRESS 
EXTERNAL; 
END WEIGHBELT$WEIGHT; 


/* DECLARATION 
OF 
LIQUID 
FLOW 
RATE 
INTERFACE 
*/ 


LIQUID$FLOW$RATE: 
PROCEDURE 
ADDRESS 
EXTERNAL; 
END 
LIQUID$FLOW$RATE; 


/* DECLARATION 
OF WEIGHBELT 
MOTOR 
DRIVE 
INTERFACE 
*/ 


WEIGHBELT$MOTOR$DRIVE: 
PROCEDURE 
(SPEED) 
EXTERNAL; 
DECLARE 
SPEED 
ADDRESS; 
END WEIGHBELT$MOTOR$DRIVE; 


/* DECLARATION 
OF LIQUID 
VALVE 
INTERFACE 
*/ 


LIQUID$VALVE$POSITION: 
PROCEDURE 
(POSITION) 
EXTERNAL; 
DECLARE 
POSITION 
BYTE; 
END 
LIQUID$VALVE$POSITION; 


/* 
DECLARATION 
OF 
PROCESSOR 
0 INITIALIZATION 
MODULE 
*/ 


PROCESSOR$0$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END 
PROCESSOR$0$INITIALIZATION; 


/* DECLARATION 
OF 
PROCESSOR 
1 INITIALIZATION 
MODULE 
*/ 


PROCESSOR$l$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END 
PROCESSOR$l$INITIALIZATION; 


/* DECLARATION 
OF PROCESSOR 
2 INITIALIZATION 
MODULE 
*/ 


PROCESSOR$2$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END 
PROCESSOR$2$INITIALIZATION; 


/* DECLARATION 
OF 
PIT COUNTER 
1 INITIALIZATION 
*/ 


COUNTER$l$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END COUNTER$l$INITIALIZATION; 


/* DECLARATION 
OF 
PIT COUNTER 
2 INITIALIZATION 
*/ 


COUNTER$2$INITIALIZATION: 
PROCEDURE 
EXTERNAL; 
END COUNTER$2$INITIALIZATION; 


/* DECLARATION 
OF 
FSP 
UNSIGNED 
LOAD 
PROCEDURES 
*/ 
42 
1 
MQULD1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
43 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
44 
2 
END 
MQULD1; 


45 
1 
MQULD2 : PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


46 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
47 
2 
END 
MQULD2; 


/* 
DECLARATION 
OF FSP 
UNSIGNED 
MULTIPLY 
PROCEDURE 
*/ 
48 
1 
MQUML1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
49 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
50 
2 
END 
MQUML1; 


51 
1 
MQUML2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
52 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
53 
2 
END MQUML2; 


/* 
DECLARATION 
OF 
FSP 
UNSIGNED 
DIVIDE 
PROCEDURE 
*/ 
54 
1 
MQUDVl: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
55 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
56 
2 
END 
MQUDV1; 


57 
1 
MQUDV2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
58 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
59 
2 
END MQUDV2; 


/* 
DECLARATION 
OF FSP 
SIGNED 
DIVIDE 
PROCEDURE 
*/ 
60 
1 
MQSDV1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
61 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
62 
2 
END 
MQSDVl; 


63 
1 
MQSDV2 : PROCEDURE 
(IR$PTR, VALUE$p'rR) EXTERNAL; 
64 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
65 
2 
END MQSDV2; 


/* 
DECLARTATION 
OF 
FSP 
SIGNED 
STORE 
PROCEDURE 
*/ 
66 
1 
MQSST2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
67 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
68 
2 
END 
MQSST2; 


/* DECLARATION 
OF FSP 
SIGNED 
LOAD 
PROCEDURE 
*/ 
69 
1 
MQSLD2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
70 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
71 
2 
END 
MQSLD2; 


/* DECLARATION 
OF FSP 
SIGNED 
SUBTRACT 
PROCEDURE 
*/ 
72 
1 
MQSSB2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
73 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
74 
2 
END 
MQSSB2; 


/* DECLARATION 
OF 
FSP 
UNSIGNED 
STORE 
PROCEDURE 
*/ 
75 
1 
MQUST1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
76 
2 
DECLARE 
(IR$PTR, VALUE$PTR) 
ADDRESS; 
77 
2 
END 
MQUST1i 


78 
1 
MQUST2: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 
79 
2 
DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
80 
2 
END 
MQUST2; 


100 
101 
102 


104 
105 


/* DECLAR~TION 
OF 
FSP 
SIGNED 
MULTIPLY 
PROCEDURE 
*/ 


MQSMLl: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 
END 
MQSMLl; 
$EJECT 
/****************************************** 
* 
DATA 
STORAGE 
AREAS 
FOR 
THE 
PID 
CONTROL 
* 


******************************************/ 


/* DEFINITION 
OF 
LIMITATION 
CONSTANTS 
*/ 


DECLARE 
MAX$MOTOR$SPEED 
LITERALLY 
'550'; 


DECLARE 
MIN$MOTOR$SPEED 
LITERALLY 
'0'; 


DECLARE 
MAX$VALVE$MOVEMENT 
LITERALLY 
'10'; 


DECLARE 
MIN$VALVE$MOVEMENT 
LITERALLY 
'-10'; 


/* DEFINITION 
OF 
PID 
PARAMETER 
DECLARE 
FEEDER$C0 
DECLARE 
FEEDER$Cl 
DECLARE 
FEEDER$C2 
DECLARE 
FEEDER$C3 
DECLARE 
FEEDER$TIME$INTERVAL 
DECLARE 
FEEDER$SCALE$FACTOR 


COEFFICIENTS 
*/ 


LITERALLY 
'1'; 


LITERALLY 
'1'; 


LITERALLY 
'I'; 


LITERALLY 
'1'; 


LI'fERALLY '1'; 
LITERALLY 
'1'; 


LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LI'l'ERALLY 


,1' ; 
,l' ; 
,l' ; 
,l' ; 
,l' ; 
, 10 ' ; 


DECLARE 
LIQUID$C0 
DECLARE 
LIQUID$Cl 
DECLARE 
LIQUID$C2 
DECLARE 
LIQUID$C3 
DECLARE 
LIQUID$TIME$INTERVAL 
DECLARE 
LIQUID$SCALE$FACTOR 


PARAMETERS 
*/ 


LITERALLY 
'0EAH'; 


LITERALLY 
'07H'; 


LITERALLY 
'0FH'; 


/* RESERVE 
18 BYTES 
FOR 
THE 
INTEGER 
RECORD 
*/ 


DECLARE 
IR 
(18) BYTE 
PUBLIC; 


/* RESERVE 
42 BYTES 
FOR 
EACH 
PID 
RECORD 
*/ 


DECLARE 
PRCV 
(42) BYTE; 
DECLARE 
PRLQ 
(42) BYTE; 


/* RESERVE 
SPACE 
FOR COUNTER 
DATA 
*/ 
DECLARE 
(LIQ$COUNT,BELT$COUNT) 
BYTE 
PUBLIC; 


/* RESERVE 
DECLARE 
C0 
Cl 
C2 
C3 
DT 
S 


12 BYTES 
FOR 
EACH 
CONSTANT 
CONSTANTSI 
STRUCTURE 
( 
ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS 
); 


/* DEFINITION 
OF RESET 
LATCH 
DECLARE 
RESET$LATCH$ADR 
DECLARE 
INDICATOR$ON 
DECLARE 
INDICATOR$OFF 


III 
112 


DECLARE 
CONSTANTS2 
STRUCTURE 
( 
C0 
ADDRESS, 
Cl 
ADDRESS," 


C2 
ADDRESS, 
C3 
ADDRESS, 
DT 
ADDRESS, 
S 
ADDRESS) 
; 


/* 
RESERVE 
8 BYTES 
FOR 
EACH 
BOUNDS 
ARRAY 
*/ 
DECLARE 
BOUNDSl 
(4) ADDRESS 
DATA 
( 
000H, 
000H, 
MAX$MOTOR$SPEED, 
MIN$MOTOR$SPEED 
); 
DECLARE 
BOUNDS2 
(4) ADDRESS 
DATA 
( 
000D, 
000D, 
MAX$VALVE$MOVEMENT, 
MIN$VALVE$MOVEMENT 
); 


/* 
RESERVE 
1 BYTE 
FOR 
EACH 
CONTROL 
BYTE 
*/ 
DECLARE 
CONTROLl 
BYTE 
DATA 
(073H); 
DECLARE 
CONTROL2 
BYTE 
DATA 
(053H); 


/* 
DECLARE 
TIME 
INTERVAL 
*/ 
DECLARE 
TIME$INTERVAL 
ADDRESS 
DATA 
(1); 


/* 
RESERVE 
SPACE 
FOR THE 
CURRENT 
BELT 
SPEED 
*/ 
DECLARE 
BELT$SPEED 
BYTE; 


/* RESERVE 
SPACE 
FOR 'rHE CURRENT 
BELT 
WEIGHT 
*/ 


DECLARE 
BELT$WEIGHT 
ADDRESS; 


/* 
RESERVE 
SPACE 
FOR THE 
LIQUID 
FLOW 
*/ 
DECLARE 
LIQUID$FLOW 
ADDRESS; 


/* 
RESERVE 
SPACE 
FOR THE 
EFFECTIVE 
SETPOINT 
*/ 


DECLARE 
MASS$SETPOINT 
ADDRESS; 


/* 
RESERVE 
SPACE 
FOR 
THE 
DESIRED 
SETPOINT 
*/ 
DECLARE 
SET$POINT 
ADDRESS; 


/*,RESERVE 
SPACE 
FOR 
THE 
DISTANCE 
OF BELT 
PER 
REVOLUTION 


*/ 
DECLARE 
DIST$REV 
BYTE 
DATA 
(100); 


/* 
DEFINE 
THE 
CONVEYOR 
LENGTH 
*/ 
DECLARE 
CONV$LENGTH 
BYTE 
DATA 
(200); 


/* DEFINE 
THE 
CONSTANT 
SIX 
*/ 
DECLARE 
SIX 
BYTE 
DATA 
(6); 


/* 
RESERVE 
STORAGE 
FOR ACTUAL 
CURRENT 
MASS 
FLOW 
*/ 


DECLARE 
MASS$FLOW 
ADDRESS; 


127 
128 


133 
134 
135 


136 
137 
138 


141 
142 


/* RESERVE 
SPACE 
FOR 
BELT 
CONTROL 
OUTPUT 
*/ 


DECLARE 
BELT$CONTROL 
ADDRESS; 


/* RESERVE 
SPACE 
FOR 
LIQUID 
RATIO 
*/ 
DECLARE 
LIQUID$RATIO 
BYTE; 


/* RESERVE 
SPACE 
FOR 
LIQUID 
CONTROL 
OUTPUT 
*/ 


DECLARE 
LIQUID$VALVE 
ADDRESS; 


/* RESERVE 
SPACE 
FOR 
RUN/HALT 
CONTROL 
*/ 


DECLARE 
SYSTEM$RUNNING 
BYTE 
PUBLIC; 


/* RESERVE 
SPACE 
FOR 
ERROR 
FIELD 
*/ 
DECLARE 
ERROR$FIELD 
ADDRESS 
DATA 
(0F800H); 


DECLARE 
DUMMY 
ADDRESS; 


/* RESERVE 
SPACE 
FOR 
PIC 
ICW BYTE */ 
DECLARE 
ICW BYTE; 


/* DEFINE 
CONSTANT 
1000 */ 
DECLARE 
THOUSAND 
ADDRESS 
DATA 
(1000); 


/* DEFINE 
CONSTANT 
0 */ 
DECLARE 
ZERO 
ADDRESS 
DATA 
(0); 


/* DEFINE 
INTERRUPT 
JUMP 
TABLE 
*/ 
DECLARE 
JUMP$TABLE 
BYTE 
AT 
(3F00H); 


/* DECLARATION 
OF PIC ADDRESSES 
ON 
ISBC 
569 BOARD 
*/ 


DECLARE 
PIC$ICWl$PTR 
LITERALLY 
'0ECH'; 


DECLARE 
PIC$ICW2$PTR 
LITERALLY 
'0EDH'; 


DECLARE 
PIC$INT$MASK$PTR 
LITERALLY 
'0EDH'; 


/* DECLARATION 
OF PIC CONSTANTS 
*/ 
DECLARE 
CLR$LOW$BITS 
LITERALLY 
'0E0H'; 


DECLARE 
INTERVAL$4 
LITERALLY 
'016H'; 


DECLARE 
INTERRUPT$MASK 
LITERALLY 
'0F4H'; 
$EJECT 
/******************************************* 
* 
INITIALIZE 
PROGRAM 
AT 
START-UP 
OF SYSTEM 
* 
* THIS 
PROCEDURE 
IS CALLED 
AT 
START-UP 
* 
*******************************************/ 


/* DISABLE 
THE 
INTERRUPTS 
*/ 
DISABLE; 


/* INITIALIZE 
PID RECORD 
*/ 
CALL 
UQPSET 
(.PRCV,.ERROR$FIELD,.DUMMY); 


CALL 
UQPSET 
(.PRLQ,.ERROR$FIELD,.DUMMY); 
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162 
163 


164 
165 


/* INITIALIZE 
THE 
CONTROL 
BITS 
*/ 
CALL 
UQPSCT 
(.PRCV,.CONTROLl)i 
CALL 
UQPSCT 
(.PRLQ,.CONTROL2)i 


/* SET 
UP THE 
PID CONSTANTS 
*/ 
CONSTANTSl.C0 
FEEDER$C0i 
CONSTANTSl.Cl 
FEEDER$C1i 
CONSTANTSl.C2 
FEEDER$C2i 
CONSTANTSl.C3 
FEEDER$C3i 
CONSTANTSl.DT 
FEEDER$TIME$INTERVALi 
CONSTANTSl.S 
FEEDER$SCALE$FACTORi 


CONSTANTS2.C0 
CONS'l'ANTS2.C1 
CONSTANTS2.C2 
CONSTANTS2.C3 
CONSTANTS2.DT 
CONS'l'ANTS2.S 


LIQUID$C0i 
LIQUID$Cl i 
LIQUID$C2i 
LIQUID$C3i 
LIQUID$TIME$INTERVALi 
LIQUID$SCALE$FACTORi 


/* CLEAR 
SETPOINTS 
*/ 
SETPOINT 
= 
0i 
LIQUID$RATIO 
= 
0i 
SYSTEM$RUNNING 
= 0i 


/* INITIALIZE 
THE 
CONSTANTS 
*/ 
CALL 
UQPSCN 
(.PRCV,.CONSTANTSl)i 
CALL 
UQPSCN 
(.PRLQ,.CONSTANTS2)i 


/* 
INITIALIZE 
THE 
BOUNDS 
*/ 
CALL 
UQPSBD 
(.PRCV,.BOUNDSl)i 
CALL 
UQPSBD 
(.PRLQ,.BOUNDS2)i 


/* SET THE 
TIME 
INTERVAL 
*/ 
CALL 
UQPSTI 
(.PRCV,.TIME$INTERVAL)i 
CALL 
UQPSTI 
(.PRLQ, .TIME$INTERVAL) 
i 


/* 
INITIALIZE 
PROCESSOR 
0 */ 
CALL 
PROCESSOR$0$INITIALIZATIONi 


/* 
INITIALIZE 
PROCESSOR 
1 */ 
CALL 
PROCESSOR$l$INITIALIZATIONi 
/* INITIALIZE 
PROCESSOR 
2 */ 
CALL 
PROCESSOR$2$INITIALIZATIONi 


/* INITIALIZE 
COUNTER 
1 */ 
CALL 
COUNTER$l$INITIALIZATIONi 


/* INITIALIZE 
COUNTER 
2 */ 
CALL 
COUNTER$2$INITIALIZATIONi 


/* INITIALIZE 
INTERRUPT 
CONTROLLER 
*/ 
ICW = 
(LOW 
(.JUMP$TABLE) 
AND 
CLR$LOW$BITS 
) OR 
INTERVAL$4 
i 
OUTPUT 
(PIC$ICWl$PTR) 
= 
ICWi 
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ICW 
= HIGH 
(.JUMP$TABLE)i 
OUTPUT 
(PIC$ICW2$PTR) 
= 
ICWi 


/* SET 
INTERRUPT 
MASKS 
*/ 
OUTPUT 
(PIC$INT$MASK$PTR) 


/* ENABLE 
INTERRUPTS 
*/ 
ENABLEi 


/* RETURN 
TO MAIN 
PROGRAM 
*/ 
RETURNi 


END INITIATIONi 
$EJECT 
/*************************************************** 
* 
THIS 
IS THE 
PID CONTROL 
ROUTINE. 
IT IS ENTERED 
* 
* 
EACH 
200 MILLISECONDS 
THROUGH 
AN 
INTERRUPT 
GEN- * 
* 
ERATED 
BY THE 
FREQUENCY 
COUNTER 
UPI AND 
SENT 
TO * 
* 
INTERRUPT 
3. 
* 


***************************************************/ 


/* TURN 
THE 
LED 
INDICATOR 
ON */ 
OUTPUT (RESET$LATCH$ADR) 
= INDICATOR$ONi 


/* GET 
WEIGHBELT 
WEIGHT 
*/ 
BELT$WEIGHT=WEIGHBELT$WEIGHTi 


/* GET 
LIQUID 
FLOW 
RATE 
*/ 
LIQUID$FLOW=LIQUID$FLOW$RATEi 


/* 
CONTROL 
START-STOP 
RAMP 
*/ 
IF SYSTEM$RUNNING 
THEN 
MASS$SETPOINT=SETPOINTi 
ELSE 
MASS$SETPOINT=0i 


/* DETERMINE 
ACTUAL 
MASS 
FLOW 
ON WEIGHBELT 
*/ 


CALL 
MQULD2(.IR,.BELT$CONTROL)i 
CALL 
MQUML2(.IR,.BELT$WEIGHT)i 
CALL 
MQUML1(.IR,.DIST$REV)i 
CALL 
MQUDV1(.IR,.CONV$LENGTH)i 
CALL 
MQSDV2(.IR,.THOUSAND)i 
CALL 
MQSST2(.IR,.MASS$FLOW)i 


/* COMPUTE 
ERROR 
SIGNAL 
ON WEIGHBELT 
*/ 
CALL 
MQSLD2(.IR,.MASS$SETPOINT)i 
CALL 
MQSSB2(.IR,.MASS$FLOW)i 


/* 
HANDLE 
PID 
BELT 
CONTROL 
ALGORITHM 
*/ 
CALL 
UQPPID(.PRCV,.IR)i 


/* 
STORE 
OUTPUT 
SIGNAL 
*/ 
CALL 
MQUST2(.IR,.BELT$CONTROL)i 
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/* 
COMPUTE 
LIQUID 
SETPOINT 
*/ 
CALL 
MQSLD2(.IR,.MASS$FLOW)i 
CALL 
MQSML1(.IR,.LIQUID$RATIO)i 
CALL 
MQSML1(.IR,.SIX)i 


/* VERIFY 
THAT 
WEIGHBELT 
IS MOVING 
*/ 
IF WEIGHBELT$SPEED 
= 
0 


THEN 
CALL 
MQULD2(.IR,.ZERO)i 


/* COMPUTE 
LIQUID 
ERROR 
*/ 
CALL 
MQSSB2(.IR,.LIQUID$FLOW)i 


/* HANDLE 
PID 
LIQUID 
CONTROL 
*/ 


CALL 
UQPPID(.PRLQ,.IR)i 


/* 
STORE 
OUTPUT 
SIGNAL 
*/ 
CALL 
MQUST1(.IR,.LIQUID$VALVE)i 


/* 
OUTPUT 
WEIGHBELT 
CONTROL 
SIGNAL 
*/ 
CALL 
WEIGHBELT$MOTOR$DRIVE 
(BELT$CONTROL)i 


/* OUTPUT 
FLOW 
CONTROL 
SIGNAL 
*/ 


CALL 
LIQUID$VALVE$POSITION 
(LIQUID$VALVE)i 


/* SEND 
END 
OF 
INTERRUPT 
TO 
8259 
CONTROLLER 
*/ 


OUTPUT(0ECH)=020Hi 


/* TURN 
THE 
LED 
INDICATOR 
OFF 
*/ 
OUTPUT 
(RESET$LATCH$ADR) 
INDICATOR$OFFi 
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/* RETURN 
FROM 
CONTROL 
TASK 
*/ 
RETURNi 
END 
PIDRUNi 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


465 
LINES 
READ 


o 
PROGRAM 
ERROR(S) 


449D 
148D 
10D 


01C 1H 
0094H 
000AH 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF MODULE 
PROCESSORINITIALIZATIONMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:F1:SBC941.0BJ 
COMPILER 
INVOKED 
BY: 
PLM80 
:F1:SBC941.PLM 
DEBUG 
PAGEWIDTH(72) 
TITLE('PR 
-OCESSOR 
INITIALIZATION') 


/********************************************** 
* THIS 
PROGRAM 
IS USED 
TO 
INITIALIZE 
THE 
ISBC * 
* 
941 
PROCESSOR 
INSTALLED 
IN SOCKET 
0. 
THE * 
* DEVICE 
WILL 
OPERATE 
IN THE 
FREQUENCY 
OUTPUT 
* 
* MODE. 
j 
* 


**********************************************/ 


/* DECLARATION 
OF ADDRESSES 
*/ 
DECLARE 
UPI$0$STATUS 
LITERALLY 
'0E5H'; 
DECLARE 
UPI$0$COMMAND 
LITERALLY 
'0E5H'; 
DECLARE 
UPI$0$DATA 
LITERALLY 
'0E4H'; 


DECLARE 
UPI$l$STATUS 
DECLARE 
UPI$l$COMMAND 
DECLARE 
VPI$l$DATA 


LITERALLY 
'0E7H'; 
LITERALuY 
'0E7H'; 
LITERALLY 
'0E6H'; 


LITERALLY 
'0E9H'; 
LITERALLY 
'0E9H'; 
LITERALLY 
'0E8H'; 


COMMANDS 
*/ 
LITERALLY 
'00BH'; 
LITERALLY 
'00DH'; 
LITERALLY 
'00EH'; 
LITERALLY 
'005H'; 
LITERALLY 
'004H'; 
LITERALLY 
'002H'; 
LITERALLY 
'001H'; 
LITERALLY 
'006H'; 


STATUS 
BITS 
*/ 
LITERALLY 
'080H'; 
LITERALLY 
'002H'; 
LITERALLY 
'010H'; 


#0 INITIALIZATION 
DATA */ 
LITERALLY 
'0B5H'; 
LITERALLY 
'000H'; 
LITERALLY 
'001H'; 
LITERALLY 
'000H'; 
LITERALLY 
'001H'; 
LITERALLY 
'000H'; 
LITERALLY 
'00EH'; 


DECLARE 
UPI$2$STATUS 
DECLARE 
UPI$2$COMMAND 
DECLARE 
UPI$2$DATA 


/* DECLARATION 
OF 
ISBC 
941 
DECLARE 
SETP1 
DECLARE 
CLRP1 
DECLARE 
CLRP2 
DECLARE 
PAUSE 
DECLARE 
LOOP 
DECLARE 
INITPF 
DECLARE 
PACIFY 
DECLARE 
ENFLAG 


/* DECLARATION 
OF 
ISBC 
941 
DECLARE 
RFC 
DECLARE 
IBF 
DECLARE 
QF' 


/* DECLARATION 
OF 
ISBC 
941 
DECLARE 
FREQ 
DECLARE 
SF 
DECLARE 
OUTPUT$ENABLE0 
DECLARE 
INITIAL$STATE 
DECLARE 
DELAY 
DECLARE 
PERIOD 
DECLARE 
INITIAL$OUTPUT 


/* DECLARATION 
OF 
INTERVAL 
DECLARE 
PIT$0$MODE 
DECLARE 
PIT$0$INTERVAL 
DECLARE 
PITS0$MODE$WRD 
DECLARE 
PIT$0$COUNT 


TIMER 
PARAMETERS 
*/ 


LITERALLY 
'01GH'; 
LITERALLY 
'00EH'; 
LITERALLY 
'0E3H'; 


LITERALLY 
'0E0H'; 


/* DECLARATION 
OF COUNTER 
LOCATIONS 
*/ 
DECLARE 
(LIQ$COUNT,BELT$COUNT) 
BYTE 
EXTERNAL; 


/* DECLARATION 
OF 
ISBC 
941 
PRIMARY 
DATA 
*/ 
DECLARE 
INIT$0$TABLE 
(6) BYTE 
DATA 
( 
FREQ, 
SF, 
OUTPUT$ENABLE0, 
INITIAL$STATE, 
DELAY, 
PERIOD 
); 


/* DECLARATION 
OF MISC 
PARAMETERS 
*/ 
DECLARE 
I BYTE; 


/*********************************************** 
* 
INITIALIZATION 
PROGRAM 
BODY 
* 


***********************************************/ 


/* INITIALIZE 
COUNTER 
0 FOR 
10 MICROSECONDS 
*/ 


OUTPUT(PIT$0$MODE$WRD)=PIT$0$MODE; 
OUTPUT (PIT$0SCOUNT)=PIT$0$INTERVAL; 


/* VERIFY 
THAT 
PROCESSOR 
IS RESET 
*/ 
DO 
WHILE 
((INPUT(UPI$0$STATUS) 
AND 
RFC) 
= 0); 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT (UPI$0$COMMAND)=PACIFY; 
END; 


/* REQUEST 
PRIMARY 
FUNCTION 
*/ 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT(UPI$0$COMMAND)= 
INITPF; 


/* LOAD 
INITIAL 
PARAMETERS 
*/ 
DO 
1=0 TO 
5; 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT(UPI$0$DATA)=INIT$0$TABLE(I); 
END; 


/* TERMINATE 
PARAMETER 
LOADING 
*/ 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$COMMAND)=PAUSE; 


/* START 
FREQUENCY 
FUNCTION 
*/ 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<>0); 


END; 
OUTPUT (UPI$0$COMMAND)=LOOP; 


/* SET 
UNUSED 
BITS 
TO ALLOW 
EXPANSION 
*/ 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$COMMAND)=CLRP2; 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$DATA)=INITIAL$OUTPUT; 


/* RETURN 
TO CALLING 
PROGRAM 
*/ 
RETURN; 


END PROCESSOR$0$INITIALIZATION; 
$EJECT 
/************************************************ 
* THIS 
PROCEDURE 
IS USED 
TO 
INITIALIZE 
THE 
ISBC * 


* 
941 PROCESSOR 
INSTALLED 
IN SOCKET 
1. 
THE DE- * 


* VICE 
WILL 
OPERATE 
IN THE 
FCOUNT, 
HIGH 
FRE- * 
* 
QUENCY 
INPUT 
MODE. 
* 
************************************************/ 


/* DEFINE 
INITIALIZATION 
PARAMETERS 
*/ 
DECLARE 
FCOUNT 
LITERALLY 
'033H'; 


DECLARE 
INPUT$SELECT 
LITERALLY 
'001H'; 


DECLARE 
OUTPUT$ENABLE$l 
LITERALLY 
'001H'; 


DECLARE 
SAMPLING$INTERVAL 
LITERALLY 
'009H'; 


DECLARE 
INITIAL$STATE$l 
LITERALLY 
'0E1H'; 


/* DECLARE 
PARAMETER 
INITIALIZATION 
TABLE 
*/ 
DECLARE 
INIT$1$TABLE(4) 
BYTE 
DATA 
( 
FCOUNT, 
INPUT$SELECT, 
OUTPUT$ENABLE$l, 
SAMPLING$INTERVAL 
); 


/************************************************ 
* 
INITIALIZATION 
BODY 
* 
~****************************~*****************~/ 


PROCESSOR$l$INITIALIZATION: 
PROCEDURE 
PUBLIC; 


/* VERIFY 
THAT 
PROCESSOR 
IS RESET 
*/ 
DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
RFC) 
= 0); 


DO WHILE 
((INPUT(UPI$l$ST~TUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND)=PACIFY; 
END; 
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/* REQUEST 
PRIMARY 
FUNCTION 
*/ 
DO WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND)=INITPF; 


/* LOAD 
INITIAL 
PARAMETERS 
*/ 


DO 
1=0 TO 
3; 
DO WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT(UPI$l$DATA)=INIT$l$TABLE(I); 
END; 


/* TERMINATE 
PARAMETER 
LOADING 
*/ 
DO WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND)=PAUSE; 


/* SET 
UNUSED 
BITS 
HIGH 
FOR 
SPARE 
ENABLES 
*/ 
DO WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND)=SETPl; 
DO WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$DATA)=INITIAL$STATE$l; 


/* START 
FREQUENCY 
COUNT 
OPERATION 
*/ 
DO WHILE 
«INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND)=LOOP; 


/* RETURN 
TO CALLING 
PROGRAM 
*/ 
RETURN; 


END PROCESSOR$l$INITIALIZ~TION; 


$EJECT 
/************************************************ 
* THIS 
PROCEDURE 
IS USED 
TO 
INITIALIZE 
THE 
ISBC * 
* 
941 
INSTALLED 
IN SOCKET 
2. THE 
DEVICE 
WILL 
BE * 
* OPERATED 
AS A STEPPER 
MOTOR 
DRIVER. 
* 
************************************************/ 


/* DEFINE 
INITIALIZATION 
PARAMETERS 
*/ 
DECLARE 
STEPPER 
LITERALLY 
'017H'; 


DECLARE 
SCALE$FACTOR 
LITERALLY 
'0DFH'; 
DECLARE 
OUTPUT$ENABLE$2 
LITERALLY 
'0F0H'; 


DECLARE 
OUTPUT$POLARITY 
LITERALLY 
'050H'; 
DECLARE 
COMMON$PERIOD 
LITERALLY 
'004H'; 


DECLARE 
P20$TRAN1 
LITERALLY 
'000H'; 


DECLARE 
P20$TRAN2 
LITERALLY 
'000H'; 


DECLARE 
P21$TRAN1 
LITERALLY 
'000H'; 


DECLARE 
P21$TRAN2 
LITERALLY 
'000H'; 


DECLARE 
P22$TRAN1 
LITERALLY 
'000H'; 
DECLARE 
P22$TRAN2 
LITERALLY 
'000H'; 
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122 
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DECLARE 
P23$TRANl 
LITERALLY 
'000H'; 


DECLARE 
P23$TRAN2 
LITERALLY 
'000H'; 


DECLARE 
P24$TRANl 
LITERALLY 
'000H' ; 


DECLARE 
P24$TRAN2 
LITERALLY 
'002H'; 


DECLARE 
P25$TRANl 
LITERALLY 
'000H'; 


DECLARE 
P25$TRAN2 
LITERALLY 
'002H'; 


DECLARE 
P26$TRANl 
LITERALLY 
'001H'; 


DECLARE 
P26$TRAN2 
LITERALLY 
'003H'; 


DECLARE 
P27$TRANl 
LITERALLY 
'001H'; 


DECLARE 
P27$TRAN2 
LITERALLY 
'003H'; 


DECLARE 
CLR$LOW$PORT 
LITERALLY 
'00FH' ; 


DECLARE 
PARAMETER 
INITIALIZATION 
TABLE 
*/ 


DECLARE 
INIT$2$TABLE(21) 
BYTE 
DATA 
( 
STEPPER, 
SCALE$FACTOR, 
OUTPUT$ENABLE$2, 
OUTPUT$POLARITY, 
COMMON$PERIOD, 
P20$TRAN 1, 
P20$TRAN2, 
P21 $TRAN 1, 
P21$TRAN2, 
P22$ARAN 1, 
P22$TRAN2, 
P23 $TRAN 1, 
P23$TRAN2, 
P24 $TRAN 1, 
P24$TRAN2, 
P25$TRAN 1, 
P25$TRAN2, 
P26$TRANl, 
P26$TRAN2, 
P27 $TRAN 1, 
P27$TRAN2 
); 
/************************************************ 
* 
INITIALIZATIOK 
BODY 
* 
************************************************/ 


PROCESSOR$2$INITIALIZATION: 
PROCEDURE 
PUBLIC; 


/* VERIFY 
THAT 
PROCESSOR 
IS RESET 
*/ 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
RFC) 
= 
0); 


DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$2$COMMAND)=PACIFY; 
END; 
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/* REQUEST 
PRIMARY 
FUNCTION 
*/' 


DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT(UPI$2$COMMAND)=INITPF; 
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137 
138 
139 


140 
141 
142 


143 
144 
145 
146 
147 
148 


/* 
LOAD 
INITIAL 
PARAMETERS 
*/ 
DO 
1=0 TO 
20; 
DO WHILE 
«INPUT(UPI$2$S~ATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT(UPI$2$DATA)=INIT$2$TABLE(I); 


END; 


/* TERMINATE 
PARAMETER 
LOADING 
*/ 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$2$COMMAND)=PAUSE; 


/* START 
STEPPER 
CONTROLLER 
OPERATION 
*/ 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) <> 
0); 


END; 
OUTPUT (UPI$2$COMMAND)=LOOP; 


/* 
SET 
UNUSED 
BITS 
LOW TO 
ENABLE 
GENERAL 
FUNCTIONS 
*/ 


DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT(UPI$2$COMMAND)=CLRP1; 
DO WHILE 
«INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$2$DATA)=CLR$LOW$PORT; 


/* 
RETURN 
TO CALLING 
PROGRAM 
*/ 
RETURN; 


END PROCESSOR$2$INITIALIZATION; 


$EJECT 
/*********************************************** 
* THIS 
PROCEDURE 
IS USED 
TO 
INITIALIZE 
COUNTER 
* 
* 1 TO 
PERFORM 
AS AN 
EIGHT 
BIT 
BINARY 
COUNTER 
* 


* WHICH 
WILL 
BE 
USED 
TO MEASURE 
THE 
BELT 
SPEED.* 


***********************************************/ 


/* INITIALIZE 
COUNTER 
1 FOR 
EIGHT 
BIT 
COUNTING 
*/ 


LIQ$COUNT 
= 
10; 


/* RETURN 
TO 
CALLING 
PROGRAM 
*/ 
RETURN; 


END COUNTER$l$INITIALIZATION; 
$EJECT 
/*********************************************** 
* THIS 
PROCEDURE 
IS USED 
TO 
INITIALIZE 
COUNTER 
* 


* 
2 TO 
PERFORM 
AS 
AN 
EIGHT 
BIT 
BINARY 
COUNTER 
* 
* WHICH 
WILL 
BE 
USED 
TO 
MEASURE 
THE 
LIQUID * 


* 
FLOW 
THROUGH 
THE 
METER. 
* 


***********************************************/ 


155 
1 
COUNTER$2$INITIALIZATION: 
PROCEDURE 
PUBLIC; 


/* INITIALIZE 
COUNTER 
2 FOR 
EIGHT 
BIT 
COUNTING 
*/ 
156 
2 
BELT$COUNT 
= 0 ; 


/* RETURN 
TO 
CALLING 
PROGRAM 
*/ 


157 
2 
RETURN; 


158 
2 
END COUNTER$2$INITIALIZATION; 


159 
1 
END 
PROCESSOR$INITIALIZATION$MODULE; 


$EJECT 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


329 
LINES 
READ 


o 
PROGRAM 
ERROR{S) 


0201H 
0001H 
0000H 


5130 
10 
00 


ISIS-II 
PL/M-80 
V3.1 
COMPILATION 
OF MODULE 
PROCESSORINTERFACEMODULE 
OBJECT 
MODULE 
PLACED 
IN 
:F1:0PR941.0BJ 


COMPILER 
INVOKED 
BY: 
PLM80 
:F1:0PR941.PLM 
DEBUG 


$INTVECTOR(4,3F00H) 
$PAGEWIDTH (72) 
$TITLE('PROCESSOR 
INTERFACE') 


/********************************************** 
* THESE 
PROGRAMS 
PROVIDE 
THE 
OPERATING 
INTER- * 
* 
FACE 
BETWEEN 
THE 
APPLICATION 
PROGRAM 
AND 
* 
* THE 
ISBC 
941 
PROCESSORS 
OR COUNTERS. 
* 
**********************************************/ 


/* DECLARATION 
OF ADDRESSES 
*/ 


DECLARE 
UPI$0$STATUS 
LITERALLY 
'0E5H'; 


DECLARE 
UPI$0$COMMAND 
LITERALLY 
'0E5H'; 
DECLARE 
UPI$0$DATA 
LITERALLY 
'0E4H'; 


DE~LARE 
UPI$l$STATUS 


DECLARE 
UPI$l$COMMAND 


DECLARE 
UPI$l$DATA 


LITERALLY 
'0E7H'; 


LITERALLY 
'0E7H'; 


LITERALLY 
'0E6H'; 


DECLARE 
UPI$2$STATUS 


DECLARE 
UPI$2$COMMAND 
DECLARE 
UPI$2$DATA 


LITERALLY 
'0E9H'; 


LITERALLY 
'0E9H'; 


LITERALLY 
'0E8H'; 


/* DECLARATION 
OF 
ISBC 
941 


DECLARE 
SETP1 


DECLARE 
CLRP1 


DECLARE 
CLRP2 


DECLARE 
RDF(,r, 


DEC LARE 
RDFC1 
DECLARE 
PAUSE 


DECLARE 
LOOP 


DECLARE 
INITPF 
DECLARE 
PACIFY 


DECLARE 
ENFLAG 


DECLARE 
SETOE 


COMMANDS 
*/ 
LITERALLY 
'00BH'; 
LITERALLY 
'00DH'; 


LITERALLY 
'00EH'; 


LITERALLY 
'042H'; 


LITERALLY 
'043H'; 


LITERALLY 
'005H'; 


LITERALLY 
'004H'; 


LITERALLY 
'002H'; 


LITERALLY 
'001H'; 


LITERALLY 
'006H'; 


LITERALLY 
'071H'; 


/* DECLARATION 
OF 
ISBC 
941 
DECLARE 
RFC 
DECLARE 
IBF 


DECLARE 
OBF 
DECLARE 
QF 


DECLARE 
QNE 


STATUS 
BITS 
*/ 
LITERALLY 
'080H'; 
LITERALLY 
'002H'; 


LITERALLY 
'001H'; 


LITERALLY 
'010H'; 


LITERALLY 
'020H'; 


/* DEFINE 
THE MATH 
ROUTINES 
USED 
BY MODULES 
*/ 
MQULD4: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


END MQULD4; 
MQUDV2: 
PROCEDURE 
(IR$PTR, VALUE$PTR) 
EXTERNAL; 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


END MQUDV2i 


MQUDV1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


END 
MQUDV1; 


MQUST1: 
PROCEDURE 
(IR$PTR,VALUE$PTR) 
EXTERNAL; 


DECLARE 
(IR$PTR,VALUE$PTR) 
ADDRESS; 


END MQUST1; 


1* DEFINE 
THE 
MATH 
ACCUMULATOR 
STORAGE 
AREA 
*1 


DECLARE 
IR(18) 
BYTE 
EXTERNAL; 


1* DEFINE 
THE 
COUNTER 
LOCATIONS 
*1 
DECLARE 
(LIQ$COUNT,BELT$COUNT) 
BYTE 
EXTERNAL; 


$EJECT 
1************************************************ 
* THIS 
PROGRAM 
IS USED 
TO GENERATE 
A 
FREQUENCY 
* 
* OUTPUT 
USING 
THE 
ISBC 
941 MODULE 
INSTALLED 
IN * 
* SOCKET 
NUMBER 
0. 
TO 
PROVIDE 
MAXIMUM 
RESOLU- 
* 
* TION, 
FOUR 
PERIODS 
WILL 
BE 
USED. 
THE FREQUEN-* 
* CY RANGES, CORRESPONDING 
TO 
EACH 
PERIOD 
ARE: 
* 
* 
RANGE 
FREQ 
RESOLUTION 
* 


11 
1 
50 TO 
165HZ 
2 HZ 
* 
* 
2 
166 TO 
225 HZ 
3 HZ 
* 
* 
3 
226 TO 
285 
HZ 
3 HZ 
* 
* 
4 
286 TO 
550 HZ 
6 HZ 
* 
* THE 
SCALE 
FACTOR 
IS COMPUTED 
BY THE 
FORMULA: 
* 
* 
SF=100000/«FREQ)*(RANGE 
FACTOR)) 
* 
************************************************1 


1* DECLARATION 
OF CONSTANT, 
100,000 
*1 
DECLARE 
HUNDRED$K(4) 
BYTE 
DATA 
( 


0A0H,086H,001H,000H 
); 


1* DECLARATION 
OF 
ISBC941 
PORT 
ENABLES 
*1 


DECLARE 
ENABLE$FREQ 
LITERALLY 
'01H'; 


DECLARE 
DISABLE$FREQ 
LITERALLY 
'00H'; 


1* DECLARATION 
OF 
ISBC 
941 MEMORY 
LOCATION 
COMMANDS 
*1 


DECLARE 
WRRM$55 
LITERALLY 
'055H'; 
DECLARE 
WRRM$74 
LITERALLY 
'074H'; 


1* DECLARATION 
OF VARIABLES 
USED 
IN COMPUTATIONS 
*1 


DECLARE 
(RANGE,FREQA) 
BYTE; 
DEC LARE 
FREQ 
ADDRESS; 
, 


1* BEGIN 
COMPUTATION 
OF 
OUTPUT 
FOR 
FREQ 
> 
48 HZ. *1 


IF FREQ 
> 
49 


THEN 
DO; 


1* ENABLE 
FREQUENCY 
OUTPUT 
*1 
DO WHILE 
«INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$COMMAND) 
= SETOE; 


54 
3 
55 
4 
56 
3 


63 
5 
64 
5 


65 
4 


66 
4 
67 
3 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$DATA) 
= ENABLE$FREQ; 


/* COMPUTATION 
OF FREQUENCY 
RANGE 
*/ 
IF FREQ 
< 
285 
THEN 
DO; 
IF FREQ 
< 
226 
THEN 
DO; 
IF FREQ 
< 
166 
THEN 
RANGE 
9; 
ELSE 
RANGE 
= 
5; 
END; 
ELSE 
RANGE 
= 3; 


END; 
ELSE RANGE 
= 
2; 


/* LOAD 
MATH 
ACCUMULATOR 
WITH 
100,000 
*/ 


CALL 
MQULD4 
(.IR, •HUNDRED$K) ; 


/* TEST 
FOR MOTOR 
SHUTDOWN 
*/ 
IF 
FREQ 
> 
1 
THEN 
DO; 


/* DIVIDE 
BY FREQUENCY 
*/ 
CALL 
MQUDV2 
(.IR,.FREQ); 


/* DIVIDE 
BY 
RNAGE 
FACTOR 
*/ 
CALL 
MQUDV1 
(.IR,.RANGE); 


/* GET 
TWO'S 
COMPLEMENT 
FOR 
ISBC 
941 
SCALE 
FACTOR 
*/ 


CALL 
MQUST1 
(.IR,.FREQA)j 
FREQA 
= NOT 
(FREQA 
+ 1); 
END; 


/* ADJUST 
FOR MOTOR 
STOP 
SIGNAL 
*/ 
ELSE 
DO; 
FREQA 
000H; 
RANGE 
0FFH; 
END; 


/* SEND 
NEW 
SCALE 
FACTOR 
TO DEVICE 
*/ 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$COMMAND) 
= WRRM$S5; 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$DATA) 
= FREQA; 


/* SEND 
NEW 
PERIOD 
TO DEVICE 
*/ 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$COMMAND) 
= WRRM$74; 


104 
105 


106 
107 
108 


109 
110 
lJ1 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$DATA) 
= RANGE; 


/* END 
OF FREQUENCY 
OUTPUT 
MODE 
*/ 
END; 


/* HANDLE 
FREQUENCIES 
< 
50 HZ. 
*/ 
ELSE 
DO; 


/* DISABLE 
FREQUENCY 
OUTPUT 
GENERATION 
*/ 
DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$COMMAND) 
= SETOE; 


DO WHILE 
((INPUT(UPI$0$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$0$DATA) 
= DISABLE$FREQ; 


/* END 
OF ALTERNATE 
FREQUENCY 
OUTPUT 
*/ 
END; 


/* RETURN 
TO 
CALLING 
PROGRAM 
*/ 
RETURN; 


END WEIGHBELT$MOTOR$DRIVE; 


$EJECT 
/***************************************************** 
* THIS 
PROGRAM 
GETS 
THE WEIGHBELT 
WEIGHT 
FROM 
THE 
* 


* NUMBER 
1 ISBC 
941 
PROCESSOR. 
THE WEIGHT 
WILL 
BE 
* 


* RECEIVED 
AS A COUNT 
WHICH 
RANGES 
BETWEEN 
0 AND 
* 


* 
2000, 
CORRESPONDING 
TO A WEIGHT 
BETWEEN 
0.0 AND 
* 


* 
10.00 
POUNDS. 
EACH 
COUNT 
RECEIVED 
HAS A 
VALUE 
* 


* OF 
0.005 
POUNDS. 
* 


*****************************************************/ 


/* DECLARATIONS 
OF 
VARIABLES 
USED 
IN THE 
PROCEDURE 
*/ 


DECLARE 
(LCOUNT,HCOUNT) 
BYTE; 
DECLARE 
WEIGHT 
ADDRESS; 


/* GET 
INPUT 
COUNT 
LOW 
BYTE 
*/ 
DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND) 
= RDFC0; 


DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
OBF) 
END; 
LCOUNT 
= INPUT(UPI$l$DATA); 


112 
113 
114 


115 
116 
117 


118 
2 


119' 
3 


120 
2 


121 
122 
123 


131 
132 


/* GET 
INPUT 
COUNT 
HIGH 
BYTE 
*/ 
DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND) 
= RDFC1; 


DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
OBF) 
END; 
HCOUNT 
= INPUT(UPISl$DATA); 


/* START 
NEXT 
WEIGHT 
SAMPLE 
PERIOD 
*/ 
DO WHILE 
((INPUT(UPI$l$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$l$COMMAND) 
= LOOP; 


/* 
CONVERT 
WEIGHT 
WEIGHT 
WEIGHT 


WEIGHT 
TO AN ADDRESS 
HCOUNT; 
SHL (WEIGHT i 8) ; 
WEIGHT 
+ LCOUNT; 


/* DIVIDE 
BY TWO 
TO CONVERT 
TO 
POUNDS 
*/ 
WEIGHT 
= SHR(WEIGHT,l); 


/* RETURN 
THE WEIGHTBELT 
WEIGHT 
*/ 
RETURN 
WEIGHT; 


END WEIGHBELT$WEIGHT; 
$EJECT 
/************************************************** 
* THIS 
PROCEDURE 
TRANFERS 
THE WEIGHBELT 
SPEED 
TO 
* 
* THE 
CALLING 
PROGRAM 
AND 
CLEARS 
THE 
COUNTER 
FOR 
* 
* THE 
NEXT 
TEST. 
THE 
SPEED 
RESOLUTION 
PROVIDES 
* 
* ONLY 
FIVE 
SPEED 
RANGES. 
* 
**************************************************/ 


/* DECLARATIONS 
OF VARIABLES 
USED 
BY THE 
PROCEDURE 
*/ 


DECLARE 
SPEED 
BYTE; 


/* LATCH 
COUNTER 
BEFORE 
READING 
SPEED 
*/ 
DISABLE; 


/* GET 
COUNTER 
VALUE 
FROM 
COUNTER 
*/ 
SPEED 
= BELT$COUNT; 


/* CLEAR 
COUNTER 
FOR NEXT 
OPERATION 
*/ 
BELT$COUNT 
0; 
ENABLE; 


/* RETURN 
DATA 
TO CALLING 
ROUTINE 
*/ 
RETURN 
SPEED; 


137 
138 


144 
145 


146 
147 


148 
149 
150 


151 
152 
153 
154 


* PUTE 
THE 
SIGNED 
MAGNITUDE 
REPRESENTATION 
FROM 
* 


* THE 
TWO'S 
COMPLIMENT 
INPUT 
AND 
WILL 
ISSUE 
THE 
* 


* APPROPRIATE 
STEP 
INCREMENT 
AND 
DIRECTION. 
A 
* 
* FIXED 
STEP 
RATE 
OF 
100 STEPS 
PER 
SECOND 
WILL 
BE 
* 
* USED 
BY THE 
CONTROL 
DEVICE. 
* 


***************************************************/ 


/* DECLARATIONS 
OF VARIABLES 
USED 
BY 
THE 
PROCEDURE 
*/ 


DECLARE 
POSITION 
BYTE; 


/* DEFINITIONS 
OF TERMS 
USED 
IN COMPUTATIONS 
*/ 


DECLARE 
STEP$RATE 
LITERALLY 
'005H'; 
DECLARE 
REVERSE 
LITERALLY 
'080H'; 


/* IF NO MOVEMENT, 
SKIP 
OPERATIONS 
*/ 
IF POSITION 
<> 
0 
THEN 
DO; 


/* SUPPORT 
CONVERSION 
TO SIGNED 
MAGNITUDE 
NUMBER 
*/ 


IF POSITION 
> 
127 
THEN 
DO; 


/* GET 
MAGNITUDE 
OF MOVEMENT 
*/ 


POSITION 
= 256 
- POSITION; 


/* SET 
SIGN 
FOR 
CCW 
ROTATION 
*/ 
POSITION 
= POSITION 
OR REVERSE; 
END; 


/* VERIFY 
THAT 
QUEUE 
SPACE 
IS AVAILABLE 
*/ 


DO WHILE 
((INPUT(UPI$2$STATUS) 
AND 
QF) 
<> 
0); 


END; 


/* REQUEST 
DESIRED 
STEP 
RATE 
*/ 
DO WHILE 
((INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$2$DATA) 
= STEP$RATE; 


/* REQUEST 
STEPPER 
MOVEMENT 
*/ 
DO WHILE 
((INPUT(UPI$2$STATUS) 
AND 
IBF) 
<> 
0); 


END; 
OUTPUT (UPI$2$DATA) 
= POSITION; 
END; 


/* RETURN 
TO CALLING 
PROGRAM 
*/ 


RETURN; 


157 
1 


158 
2 
159 
2 


160 
2 


161 
2 


162 
2 
163 
2 


164 
2 
165 
2 
166 
2 


167 
2 
168 
2 


169 
2 


170 
2 


$EJECT 
/***************************************************** 
* 
THIS 
PROCEDURE 
TRANSFERS 
THE 
LIQUID 
FLOW 
RATE 
FROM * 
* THE 
FLOW 
COUNTER 
TO THE 
CALLING 
PROGRAM. 
AFTER 
* 
* READING, 
THE 
FLOW 
COUNTER 
WILL 
BE RESET 
TO 
FACILI- 
* 
* TATE 
THE 
NEXT 
READING. 
THE 
LIQUID 
FLOW 
COUNT 
WILL * 


* 
VARY 
BETWEEN 
20 AND 
240 
PULSES 
IN EACH 
200 MILLI- 
* 
* SECOND 
SAMPLE 
INTERVAL. 
THIS WILL 
CORRESPOND 
TO 
* 
* THE ACTUAL 
LIQUID 
FLOW 
RATE 
OF 
10 TO 
120 POUNDS 
* 


* 
PER 
MINUTE. 
* 


*****************************************************/ 


LIQUID$FLOW$RATE: 
PROCEDURE 
ADDRESS 
PUBLIC; 


/* DECLARATION 
OF VARIABLES 
USED 
BY THE 
PROGRAM 
*/ 


DECLARE 
TEMP 
BYTE; 
DECLARE 
(FLOW,T$TWO,T$SXTN,T$THRTWO) 
ADDRESS; 


/* LATCH 
COUNTER 
BEFORE 
READING 
FLOW 
*/ 
DISABLE; 


/* GET 
FLOW 
RATE 
VALUE 
FROM 
COUNTER 
*/ 
TEMP 
= LIQ$COUNT; 


/* CLEAR 
COUNTER 
FOR NEXT 
OPERATION 
*/ 
LIQ$COUNT 
= 0; 
ENABLE; 


/* 
CONVERT 
TO POUNDS 
PER MINUTE 
*/ 
FLOW 
= TEMP; 
T$TWO 
= SHL(FLOW,l); 
T$SXTN 
= SHL(T$TWO,3); 
T$THRTWO 
= SHL(TSSXTN,I); 
FLOW 
= T$TWO 
+ T$SXTN 
+ T$THRTWO; 


/* RETURN 
FLOW 
RATE 
TO CALLING 
PROGRAM 
*/ 
RETURN 
FLOW; 


END LIQUID$FLOW$RATE; 


$EJECT 
/******************************************** 
* 
COUNTER 
FOR 
LIQUID 
FLOW 
RATE 
FROM 
LIQUID 
* 
* 
FLOW 
METER. 
COUNT 
PULSE 
WILL 
GENERATE 
AN * 
* 
INTERRUPT 
AT 
LEVEL 
1. 
* 
********************************************/ 


171 
1 
LIQ$CNT: 
PROCEDURE 
INTERRUPT 
1 PUBLIC; 


/* 
INCREMENT 
FLOW 
COUNT 
*/ 


172 
2 
LIQ$COUNT 
= LIQ$COUNT 
+ 
1; 


/* SEND 
END 
OF 
INTERRUPT 
*/ 


173 
2 
OUTPUT 
(0ECH) 
= 
020H; 


180 
181 


/* RETURN 
*/ 
RETURN; 


END LIQ$CNT; 


$EJECT 
/************~****~************************** 
* THIS 
PROCEDURE 
WILL 
PROVIDE 
AN 
EVENT 
COUN-* 


* TER 
TO HANDLE 
THE 
BELT 
MOTION 
DETECTOR. 
• * 


* IT WILL 
OPERATE 
BY DIRECTING 
THE 
MOTION 
* 


* PULSE 
TO 
INTERRUPT 
2. 
* 


********************************************/ 


BELT$CNT: 
PROCEDURE 
INTERRUPT 
0 PUBLIC; 


/* 
INCREMENT 
BELT 
MOVEMENT 
*/ 
BELT$COUNT 
= BELT$COUNT 
+ 1; 


/* 
SEND 
END 
OF 
INTERRUPT 
*/ 
OUTPUT 
(0ECH) 
= 020H; 


/* RETURN 
*/ 
RETURN; 


END BELT$CNT; 
END 
PROCESSOR$INTERFACE$MODULE; 


CODE 
AREA 
SIZE 


VARIABLE 
AREA 
SIZE 


MAXIMUM 
STACK 
SIZE 


400 
LINES 
READ 


o PROGRAM 
ERROR(S) 


END 
OF PL/M-80 
COMPILATION 


0251H 
0013H 
0008H 
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Designing and Assembling 
Microcomputer Systems Grows Easier 


Although a single data bus standard yet eludes the microcomputer industry, numer- 
ous manufacturers of single-board computer and supplementary boards have cast a 
hardware vote for the Multibus, Intel's microcomputer backplane which they origina- 
ted in 1976. With a steady eye on the control industry market, Intel has designed a 
home to accommodate 
Multibus compatible equipment. the iCS-80 industrial chas- 


sis. It promises to significantly reduce the time and cost of assembling the housing 
and interface parts of a microcomputer-based 
control system. In this article, besides 
taking the first look at Intel's new chassis and signal conditioning panels, we've put 
together a comprehensive 
list of Multibus compatible equipment. 


After the development 
of single-board 


computers nearly three years ago, ven- 
dors moved quickly to seize a fraction of 
the market. It seemed at first that every- 
thing 
from 
memories 
to analog 
1/0 
boards had become available. With an 
astonishing 
suddenness, 
companies 
sprang up in Silicon Valley, Texas, New 
Jersey, and along the forested roadside 
of Rt. 128 outside of Boston. Late that 
year, we counted well over a hundred 
companies 
anxious to make their for- 
tune selling the control engineer every- 
thing from one or two interface boards 
to complete microprocessor 
systems. 


Then the pleasant dream became a 
nightmare 
From power supply require- 


ments to backplane 
pinouts, little was 


compatible. Even such an obvious thing 
as board size differed from vendor to 
vendor and many a hope for an ideal 
system was crushed 
in a pragmatic 
search for whatever would fit together. 


Seven months ago in our June 1978 


issue we noted that the number of mi- 
crocomputer 
system 
manufacturers 
had dwindled 
to about 60 and since 


then, we find still fewer. Some, no doubt, 
were forced 
out for lack of reliability, 


though 
most, despite 
remarkably 
ta- 


lented engineering, starved as the mar- 
ket saturated. 


Large scale integration of microcom- 


puter 
components 
has 
more 
than 
doubled 
the memory 
size of single- 
board 
computers. 
Sixteen 
bit word 
lengths will become commonplace 
in 
the next year as microcomputer perfor- 
mance 
begins 
to 
rival 
the 
mini- 


computer's 
and the lines of distinc- 
tion between micros and minis fades 


The fight for a standard 
data bus 


drags on with leaders in the struggle but 
no winner. On the offensive, Pro-Log 
and Mostek jointly introduced the STD 
bus last autumn in an attempt to gain a 
greater market share by espousing de- 
centralized system architectures. Their 
philosophy argues economics: the user 
should pay only for essential functions 
by selecting small, specialized boards 


and not squander funds on a general 
purpose board with extra features. 
Still, 
Intel, 
favoring 
more densely 


packed and versatile boards. continues 
to dominate the market while the Multi- 
bus retains its popularity. Today more 
30 manufacturers 
produce 
over one 
hundred different boards based on that 
bus structure alone. Not that Intel enjoys 
the strict fidelity of its outside vendors; 
Digital Equipment Corporation, for in- 
stance, 
boasts 
some 17 companies 
providing 
boards 
to mate 
with 
the 
LSI-11 and LSI-112. 


MOUNTING 
SPACE FOR 
SIGNAL 
CONDITIONING 
TERMINATION 
PANELS 


But perhaps alone among its compet- 
itors, Intel has recognized that the ma- 
jority of its boards are being used in 
industrial applications and that the con- 
trol system designer needs more than 
components. 


An industrial chassis 
A microcomputer system designer must 
choose components 
that are electro- 


mechanically 
compatible. 
To that end, 


Intel is introducing the iCS-80 industrial 
chassis 
and 
termination 
panels. 
It 


makes 
all Multibus-compatible 
CPU 


SLIDE IN/OUT 
MOUNTING FOR 
'SBC 635(14 AMPI 
or640 (30 AMP) 
POWER SUPPLIES 


-BOTH 


RETMA 19" 
(FRONT) 
AND 
NEMA 
(REAR) 
MOUNTING 
KITS 
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and peripheral boards readily usable. 
The advantage of the ICS-80 is that 


most of the interconnection 
and me- 


chanical 
details 
for 
assembling 
a 


microcomputer-based 
control system 


have already been worked out. 


The iCS-80 stands 15.75 inches high 


and 
can be mounted 
in a stardard 
RETMA 19 inch rack, or in a NEMA cabi- 
net secure from the industrial environ- 
ment. The minimum layout consists of a 
four-slot Multibus card cage with provi- 
sions for adding two more cages to a 
maximum of twelve cards. The cages fit 
vertically, like records in a rack, to aid 
convection cooling and permit front ac- 
cess for insertion and maintenance. 
On the right side of the chassis is 


room for either a 14or 30 ampere power 
supply, the choice dictated by the ap- 
plication. 
The system will operate on 
either 115 or 230 volts with a range of 47 
to 63 Hertz specified in anticipation of 
international service 


Cooling 
is assisted 
by four fans- 


three for the card cages and one for the 
power 
supply 
section 
The intention 
here is to make the installation of addi- 
tional fans unnecessary even after the 
system has expanded. The fans are ex- 
pected to provide adequate cooling for 
most applications so supplementary air 
conditioning 
can be eliminated 
or at 


least minimized. 


Signal conditioning 
Three signal conditioning 
panels have 


been developed by Intel to simplify con- 
nections between the processing cards 
and the outside world. The principle is 
neatness, and with that follows reliabil- 
ity. Flat ribbon cables connect the sig- 
nal conditioners to the processor cards, 
a safeguard from "which wire is which" 
and screwdriver 
slips in the vicinity of 


expensive boards. Field connections to 
the external 
inputs 
and outputs 
are 
made (presumably by electricians with 
big hands and reputations 
for being 
less than delicate) 
through 
rugged, 
screw-type 
barrier strips that accept 


wire as heavy as 14 AWG. The panels 
can mount either on RETMA 
cabinet 
brackets, NEMA wall spacers, or on the 
iCS-80 chassis itself. 
Each signal conditioning 
card gives 
the user a variety of options. The iCS-910 
analog signal conditioning/termination 
panel accepts up to 16 differential or 32 
single ended input channels. The four 
2-wire analog output channels might be 
connected to 4 to 20 mA current loops. 


The digital signal conditioning termi- 


nation panel, iCS-920, handles 24 two- 
wire input or output channels with sig- 
nals up to 55 V, 300 mA. Inputs can be 
diode 
protected, 
and pads are pro- 


vided for current limiters or voltage di- 
viders. Optoisolators may be inserted in 
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the DIP sockets for high voltage isola- 
tion or jumpers may be used instead 
when the input is TTL. Similarly, output 
sockets accept jumpers for direct TTL 
output, 
DIP optoisolators 
for transient 
suppression, or integrated circuit (open 
collector) 
drivers 
for high voltage' to 
high current outputs. Activity on each 
channel is indicated by LEOs. 


The ac signal conditioning/(solidas) 
termination panel, iCS-930, will actually 
work with ac or dc on its 16 channels. 
The user supplies optoisolators for input 
isolation 
and optically-isolated 
solid 
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state relays for output isolation 
Mount- 
ing pads for customer-supplied 
MOVs 


or snubber networks are included. As 
before, a fuse gives overload protection 
and LEOs indicate channel activity. 


The advantage 
of all this is that by 


plugging in some components and per- 
haps inserting a few resistors and capa- 
citors, the interface units can be tailored 
to a particular application. Since many 
mechanical 
and electrical connection 


problems have already been solved, a 
customized 
unit can be built with mini- 


mum effort. 
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